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SECTION  I 

INTRODUCTION 


The  purpose  of  this  manual  is  to  document  the  Modular  Air  Defense 
Model  (MADEM)  simulation.  It  is  designed  for  use  by  analysts  who  wi-h  to 
use  MADEM  in  a  study.  Programmers  charged  with  maintaining  or  modifying 
the  MADEM  software  are  referred  to  the  MADEM  Programmer  Manual. 

Chapter  II  of  this  manual  contains  an  executive  summary  of  MADEM  cnieT' 
characteristics.  An  overview  of  the  MADEM  System  is  provided  in  Chapter 
III.  It  is  intended  as  a  quick  reference  to  MADEM' s  general  capabilities 
and  1 i mi tati ons . 

Chapter'  IV  contains  detailed  documentation  of  the  nrocesses  modeled  in 
MADEM.  It  is  followed  by  a  detailed  discussion  of  MADEM  operation  with 
emphasis  on  specific  input  requi cements  in  Chapter  J.  An  example  case, 
including  all  inputs  and  required  Job  Control  Language  is  provided  in 
Chapter  VI . 


SECTION  II 
EXECUTIVE  SUMMARY 


A.  PURPOSE,  SCOPE ,  AND  METHODOLOGY 


The  Modular  Air  Defense  Effectiveness  Model  (MADEM)  was  developed  by 
the  BDM  Corporation  to  support  a  Defense  Nuclear  Agency  (DNA)  evaluation  of 
the  role  of  nuclear  weapons  in  NATO  air  defense.  MADEM  encompasses  the 
entire  NATO  (Blue)  air  defense  structure  including  generation  of  a  system¬ 
atic  theaterwide  Warsaw  Pact  (Red)  attack  plan.  Figure  1 1 - 1  illustrates 
the  scope  of  MADEM. 

MADEM  has  several  unique  characteri sties  which  distinguish  it  from 
other  Theater  Level  Air  Defense  Models.  Most  significant  among  these  is 
the  use  of  a  player-centered  design  in  which  key  units  and  flights  in  the 
air  defense  system  are  explicitly  modeled.  This  approach  also  allows 
modeling  of  individual  unit  perceptions  based  on  the  information  that  would 
be  available  to  the  unit  in  a  similar  real  world  situation.  In  addition  to 
explicit  unit  modeling,  MADEM  also  uses  a  list  processing  data  storage 
system  to  explicitly  represent  the  command,  control  and  communications 
networks  which  link  units  in  the  air  defense  system.  These  explicit  repre¬ 
sentations  of  air  defense  system  elements  are  combined  with  a  hex  based 
coordinate  system  which  allows  maximum  unit  movement  flexibility  with 
minimal  data  storage  requirements.  The  result  is  a  flexible  model  capable 
of  representing  a  variety  of  combat  processes.  Tab  e  1 1  - 1  summarizes  the 
major  processes  modeled  in  MADEM. 

While  MADEM  does  extend  many  modeling  aspects  beyond  what  had  been 
previously  achieved  and  does  contain  some  unique  characteristics,  it  is 
like  other  models  in  that  it  must  be  used  as  a  relative  rather  than  an 
absolute  tool.  Results  generated  by  MADEM  should  be  used  only  in  this 
context. 
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Scope  of  MADEM 


f 


1 


TABLE  1 1 -1 .  PROCESSES  MODELED 


PROCESSES 

PLANNING  OF  AIR  ATTACK 
BY  PACT 

ALLOCATION/ASSIGNMENT  OF 
PACT  PENETRATORS 

AIRCRAFT  INITIATED  COMBAT 

GROUND-TO-AIR  COMBAT 


LEVEL  OF  DETAII 

MULTIPLE  RAIDS  AGAINST  SPE¬ 
CIFIC  TARGETS  BASED  ON 
STRATEGIC/TACTICAL  CHARACTER¬ 
ISTICS  OF  BATTLE,  AIRCRAFT 
AND  TARGETS 

CRC/BOC/BTRY/I NTERCEPTOR 
INTERACTIONS  AND  AUTONOMOUS 
OPERATIONS  PLAYED  EXPLICITLY 

AIR-TO-AIR  COMBAT  AND  AIR- 
TO-GROUND  ATTACK  EFFECTS 
BETWEEN  INDIVIDUAL  FLIGHTS 
ASSESSED 

EFFECTS  OF  INDIVIDUAL  MISSILE 
FLYOUTS  FROM  SPECIFIC  FIRE 
UNITS  AGAINST  SPECIFIC  AIR¬ 
CRAFT  ASSESSED 

EFFECTS  OF  NUCLEAR  WEAPONS/ 
ACQUISITION  CHARACTERISTICS/ 
IFF/EARLY  WARNING  COMMUNICA¬ 
TIONS  DELAY 
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B.  OATA  BASE  DESCRIPTION 


The  data  base  size  depends  on  the  situation  to  be  modelled.  The 
aircraft  modeling  characteristics  are  described,  as  well  as  how  flights  and 
formations  are  formed.  Flight  profiles,  the  numbers  of  aircraft  on 
different  air  bases  and  system  characteristics  of  the  different  air  defense 
systems  are  also  specified.  Probability  of  acquisition,  detection  and  of 
kills  for  the  different  system  are  described  in  the  data  base.  MADEM  also 
has  an  input  language  for  the  specific  scenario  description.  The  command 
structure  and  unit  location  as  well  as  the  general  orders  for  the  Red 
attack  are  described  in  English-like  sentences  for  user  ease.  Figure  1 1 - 2 
shows  a  typical  input  language  file  entry. 

C.  PRIMARY  OUTPUTS 

MADEM  is  a  discrete  event  simulation.  A  complete  event  trace  is 
available  for  all  significant  events.  A  "history"  file  is  also  generated 
during  the  course  of  the  simulation.  This  file  can  be  used  as  input  to  a 
post  processor  which  recovers  relevant  statistical  information  in  tabular 
form.  At  present,  records  are  kept  on  system  acquisition,  engagements, 
kills,  missiles  fired,  number  of  penetrators  reaching  target,  and  damage 
levels  for  key  units. 

D.  APPLICATIONS 


Subsequent  to  its  development,  MADEM  has  been  successfully  used  to 
evaluate  the  performance  of  alternate  threat  forces  and  air  defense  force 
capabilities  in  support  of  study  efforts,  and  to  compare  and  evaluate  the 
sensitivity  of  various  assumptions  about  system  performance  capabilities  on 
overall  theater  air  defense  effectiveness.  Table  1 1 - 2  summarizes  MADEM's 
potential  application  areas. 
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USER  INPUTS  GENERAL  ALLOCATION  SCHEME  TO  MODEL,  PLANNING 
FUNCTIONS  IN  THE  MODEL  ASSIGN  SPECIFIC  AIRCRAFT  TO  HIT  THE 
TARGET,  AND  CALCULATES  THE  FLIGHT  PLAN. 

USER  INPUT  EXAMPLE: 

RAID  1, 

CORRIDOR  1  LIMITS  ARE  50,25  LAT  12,0  LONG,  50.33  LAT 
11.64  LONG 

CORRIDOR  1  DEPTH  IS  70  KM  HEADING  245  DEG,  SPREAD 
ANGLE  60  DEG, 

BUFFER  ZONE  WIDTH  IS  40  KM. 

WAVE  1  START  TIME  IS  0430  HRS  DAY  1  FOR  5  MIN, 

TARGET  TYPE  HAWK  BTRYS,  1  FORMATION,  150,  OKM  RANGE 
LIMITS 

2  TYPE  3  FORMATIONS 


Figure  1 1 -2 .  Typical  Input  Language  File  Entry 


TABLE  1 1-2,  MAD EM  APPLICATION  AREAS 


EFFECTS  C3  STRUCTURES  AND  TECHNOLOGIES  ON  OVERALL 
CONFLICT  OUTCOME 

EFFECTS  OF  IMPROVED  TECHNOLOGY  IN  WEAPONRY  AND 
ACQUISITION/IDENTIFICATION  SYSTEMS  OF  BOTH  AIRCRAFT 
AND  SAM  UNITS 

EXAMINATION  OF  POLICY  AND  DOCTRINE  REGARDING 
DEPLOYMENT  AND  TACTICAL  OPERATION  OF  AIR  DEFENSE 
UNITS  FOR  BOTH  BLUE  AND  RED 

ROLE  AND  EFFECTS  OF  LOGISTICS  ON  THE  AIR  DEFENSE 
POSTURE  DURING  A  SUSTAINED  CONFLICT 

ROLE  OF  NUCLEAR  WEAPONS  IN  AN  AIR  DEFENSE/AIR 
DEFENSE  SUPPRESSION  ROLE 
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E.  OPERATING  ENVIRONMENT 


MADEM  wac  developed  on  the  Cyber  176  computer  at  the  Air  Force  Weapons 
Laboratory  (AFWL).  It  is  coded  in  CDC  extended  FORTRAN  and  Compass.  In 
its  present  form  MADEM  can  be  run  on  the  CDC  6600,  CDC  7600  and  Cyber  176 
computers  using  the  FORTRAN  compiler. 

MADEM  contains  22,500  FORTRAN  source  lines  with  280  subroutines.  The 
131,000  word  data  storage  area  requires  large  core  or  extended  core 
storage. 
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SECTION  III 

OVERVIEW  OF  THE  MADEM  SYSTEM 


A.  INTRODUCTION 


The  purpose  of  this  chapter  is  to  introduce  the  reader  to  the  basic 
architecture  of  MADEM  and  the  major  processes  modeled.  Both  the  archi¬ 
tecture  and  processes  modeled  are  documented  in  greater  detail  in  Chapter 
III. 

B.  MODEL  ARCHITECTURE 

1 .  MADEM  Players 

Active  players  modeled  in  MADEM  include  Control  and  Reporting 
Centers  (CRC),  airbases,  Battalion  Operation  Centers  (BOC),  fire  units,  and 
Aircraft  Warning  and  Control  Systems  (AWACS)  as  well  as  the  Warsaw  Pact 
flights  and  formations.  Non-players  include  targets  such  as  Specie  1 
Ammunition  Supply  Points  (SASP),  nuclear  surface-to-surface  delivery  units, 
and  command  posts.  Players  are  capable  of  acquiring  and  retaining  per¬ 
ceptions  of  their  environment  and  making  decisions  based  on  a  given  logic 
structure.  By  communicating  with  one  another  within  the  command  structure, 
p’ayers  are  capable  of  generating  the  necessary  stimuli  to  sustain  a  con¬ 
tinuing  series  of  coordinated  activities. 

2.  Geographical  Accounting 

MADEM  uses  a  hexagonal  coordinate  structure  for  geographical 
accounting.  This  permits  greater  efficienty  and  flexibility  for  movement. 
The  topological  character  of  hexagons  coupled  with  a  unique  numbering 
system  permits  varying  levels  of  detail.  The  smallest  hexagon  used  in 
MADEM  is  9.45  kilometers  wide.  Seven  such  hexagons  form  a  larger  25.9 
kilometer  hexagon.  Other  hexagon  sizes  are  available  but  not  used  in 
MADEM.  Reference  Figure  III-l. 

3.  Actions  Based  on  Perceptions 

MADEM  is  a  player  centered  model.  All  processes  simulated  in  the 
model  are  initiated  by  actions  taken  by  player  units.  Players  initiate 
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Figure  III-l.  Example  of  Hexagonal  Structure 


r 


actions  based  on  perceptions  of  the  environment  received  through  their 
acquisition  and  communications  devices.  The  nature  and  status  of  the 
units'  acquisition  and  communications  devices  will  determine  the  extent  to 
which  perceptual  data  is  distorted.  For  example,  it  is  possible  for  inter¬ 
ceptors  to  incorrectly  identify  a  Blue  flight  as  a  Red  flight  and  fire  on 
it. 

4.  Modul ari ty 

The  model  was  developed  along  functional  lines  so  that  each  major 
function  exists  as  semi - i ndependent  section  of  the  model.  Each  major 
function  is  referred  to  as  a  module.  The  modules  are  further  divided  into 
smaller  segments  each  of  which  contains  the  logic  for  a  single  decision  or 
physical  operation.  The  modules  are  tied  together  through  a  centralized 
software  control  system  that  manages  the  overall  functioning  of  the  model. 
This  multi-module  configuration  is  illustrated  in  Figure  1 1 1 - 2. 

The  modularity  of  MADEM  simplifies  the  process  of  adding  new 
modules  or  modifying  existing  modules.  Each  can  be  accomplished  with  a 
minimum  amount  of  effort  since  all  modules  are  linked  both  operationally 
and  functionally  through  the  simulation  control  software. 

5.  MADEM  Capabilities  and  Constraints 

Besides  modeling  the  fundamental  air  defense  functions  of 
acquisition,  identification,  assignment,  engagement  and  analysis,  MADEM  is 
able  to  plan  raids.  It  accomplishes  this  by  matching  available  resources 
against  a  given  target  base.  Following  a  raid,  MADEM  assesses  perceived 
damage  to  the  target  base  and  the  known  attrition  of  threat  aircraft  and 
schedules  the  next  raid.  This  process  is  repeated  as  often  as  desired 
without  interruption  of  a  production  run. 

The  number  of  events  and  variety  of  activities  that  can  be  real¬ 
istically  expected  to  occur  in  a  large  scenario  in  a  short  time  frame  is 
significantly  large.  For  instance,  a  typical  MADEM  historical  file  con¬ 
tains  over  80  events  printed  for  each  second  of  battle  (during  intense 
periods).  For  each  event  printed,  three  or  more  events  occur  but  are  not 
pri nted. 

Since  most  real  life  activities  can  not  be  precisely  modeled  or 
predicted,  one  should  treat  the  absolute  output  parameters  of  MADEM  with 
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Figure  III-2.  Example  of  Modular  Construction 


20 


caution.  They  may  or  may  not  represent  precise  outcomes  of  given 
scenarios.  The  principal  value  of  MADEM  lies  in  its  ability  to  fairly 
approximate  a  given  situation  for  comparison  and  relative  analysis  of 
scenario  variations. 

C.  MAJOR  PROCESSES  MODELED 

1 .  Red  Threat  Planning 

a.  Primary  Input  Data 

(1)  Warsaw  Pact  air  base  locations, 

(2)  Number  and  type  of  aircraft  available  at  each  air  base  (basing), 

(3)  Command  structure  for  scheduling  and  rescheduling  raids, 

(4)  Corridor  locations  and  characteristics , 

(5)  Aircraft  speed,  altitude,  and  combat  radius, 

(6)  Wave  start  times  and  durations, 

(7)  Flight  types  and  formation  descriptions, 

(8)  Strike  criteria  for  target  types  by  wave  and  raid 

b.  Red  Threat  Planning  Capabilities 

MADEM  plans  each  wave  and  raid  by  matching  formation  and 
targeting  requirements  with  basing  and  corridor  information.  Subsequent 
raids  are  based  upon  Warsaw  Pact  aircraft  attrition,  new  targeting  require¬ 
ments,  and  perceptions  of  damage  caused  by  previous  raids.  Figure  1 1 1  -  3 
illustrates  this  scenario. 

MADEM  moves  aircraft  "flights".  Each  flight  consists  of  a 
grouping  of  homogeneous  type  aircraft  scheduled  against  a  preselected 
target  (targeting  planned  by  MADEM).  A  "type  flight"  consists  of  a 
specified  number  of  aircraft,  depending  on  the  type  target  it  is  designed 
to  attack.  Individual  aircraft  are  not  tracked,  but  are  accounted  for  when 
the  flight  is  attacked  and  aircraft  kills  result. 

An  aggregation  of  flights  constitutes  a  formation  (Figure  1 1 1 - 4 ) , 
formations  constitute  waves,  and  waves  constitute  raids.  MADEM  completes 
two  raids  in  a  single  iteration  by  assessing  the  previous  raid  and  planning 
the  subsequent  raid.  Separate  iterations  may  be  run  for  each  air  defense 
alternative. 
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Figure  III -4 .  Formation  Structure 


Waves  are  passed  through  user  selected  corridors  and  attack 
scheduled  targets  within  bounds  prescribed  by  the  user  (e.g.,  maximum  and 
minimum  ranges,  type  targets,  corridor  "spread  angles"  and  "boundaries"). 
Flights  change  course  to  negotiate  passage  through  corridors  and  thereafter 
follow  a  piecewise  linear  course  to  their  target  and  return  to  home  base. 
Flights  change  altitude  in  accordance  with  user  input.  If  a  flight  fails 
to  detect  its  assigned  target,  there  is  no  opportunity  to  serach  for  other 
targets  and  the  flight  returns  to  home  base  without  inflicting  damage. 
Flights  report  perceived  target  damage  which  is  used  for  subsequent  strike 
scheduling.  Figure  I I I- 5  illustrates  this  scenario, 
c.  Red  Threat  Planning  Data  Output 

(1)  The  number  and  type  of  flights  assigned  to  attack  specific 
targets  from  each  airbase, 

(2)  The  flight  path  for  each  flight,  including  its  formation 
rendezvous  point,  passage  through  the  attack  corridor,  approach 
to  target  and  return  to  base, 

(3)  Target  locations  and  unit  numbers. 

2.  Ai r-to-Surface  Battle 

a.  Primary  Input  Data 

(1)  Ground  target  types  and  locations, 

(2)  Probabilities  for  locating  (detecting)  ground  targets, 

(3)  Criteria  for  neutralizing  fire  units,  and 

(4)  Fractional  damage  table  for  ground  targets. 

b.  Ai r-to-Surface  Capabilities 

Each  flight  is  given  a  probability  of  detecting  its 
scheduled  target  based  on  the  nature  of  the  target. 

Tactical  Ai r-to-Surface  Missiles  (TASM)  are  played  but  are 
not  released  until  within  the  same  hexagon  as  the  target.  This  means  that 
the  carrier  aircraft  may  be  exposed  to  attack  for  an  additional  one  or  two 
minutes  prior  to  the  time  it  might  realistically  have  released  its 
ordnance. 

No  target  in  Warsaw  Pact  territory  is  attacked.  In  par¬ 
ticular,  Warsaw  Pact  air  bases  are  not  damaged  and  hence  aircraft  are  not 
attrited  because  of  NATO  counterstrikes. 
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Figure  III-5.  Scenario  Controls 
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Damage  to  ground  targets  is  assessed  according  to  the  nature 
of  the  target.  Some  targets,  such  as  air  defense  fire  units,  are  either 
1 OOio  destroyed  or  not,  dependent  upon  a  Monte  Carlo  process  for  the  par¬ 
ticular  ordnance  used  (assumes  the  specific  targets  are  the  radars).  Other 
targets  such  as  depots,  command  posts,  and  nuclear  delivery  units  are 
damaged  in  a  cumulative  manner  based  on  the  number  and  type  of  ordnance 
used  against  the  specific  target. 

c)  Ai r-to-Surface  Data  Output 

(1)  The  number  and  types  of  aircraft  reaching  their  specified  tar¬ 
gets, 

(2)  Fractional  damage  of  the  given  set  of  targets,  and 

(3)  Air  defense  fire  units  neutralized. 

3.  Air-to-Air  Battle 

a.  Primary  Input  Oata 

(1)  NATO  airbase  locations  with  number  and  type  aircraft, 

(2)  Aircraft  ordnance  loading  and  combat  radius, 

(3)  NATO  interceptor  flight  sizes, 

(4)  Probabi 1 i ties  of  kill  for  Warsaw  Pact  and  NATO  air-to-air 
ordnance  types ,  and 

(5)  Operational  availability  of  interceptors  is  addressed  by  randomly 
withholding  appropriate  numbers  and  types  from  the  model. 

b.  Air-to-Air  Capabilities 

The  Control  and  Reporting  Centers  (CRC)  scramble  inter¬ 
ceptors  upon  demands  caused  by  the  threat.  They  are  scrambled  when  hostile 
flights  are  detected  but  are  not  assigned  to  specific  flights  until  air¬ 
borne.  Flight  sizes  are  fixed  in  size  based  on  user  input.  The  flight  is 
vectored  to  an  intercept  point  by  the  CRC  (or  AWACS)  until  within  detection 
range  of  the  hostile  flight.  As  the  threat  changes  course,  the  intercept 
point  is  relocated  accordingly.  Visual  and/or  radar  acquisition  occurs 
when  the  interceptor  flight  approaches  within  acquisition  range  of  the 
hostile  flight.  Probability  of  kill  is  based  on  type  of  ordnance  loadings 
for  both  NATO  and  Warsaw  Pact  flights.  Targets  of  opportunity  may  occur 
when  flights  find  themselves  unexpectedly  in  close  proximity  to  each  other 
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(e.g.,  within  20  km).  Interceptors  return  to  their  departure  air  base  when 
the  hostile  flight  has  been  destroyed  or  when  fuel  and/or  ordnance  has  been 
expended.  If  communications  to  the  CRC  have  been  interrupted  the  flight 
will  return  to  its  airbase. 

Once  interceptor  flights  are  landed,  a  60  minute  (a  variable 
user  input)  delay  time  is  incorporated  in  the  model  to  account  for 
rearming,  refueling,  and  minor  repair  time.  Subsequent  to  this  delay, 
interceptors  become  available  for  new  assignments.  In  the  current  model, 
NATO  airbases  are  assumed  available  to  service  returning  interceptor 
flights  regardless  of  the  amount  of  damage  to  the  air  bases,  and  aircraft 
on  the  ground  at  the  time  of  an  attack  are  not  destroyed, 
c.  Air-to-Air  Data  Output 

(1)  Flights  acquired  and  engaged;  aircraft  destroyed, 

(2)  NATO  interceptors  destroyed. 

4.  Surface-to-Ai r  Battle 

a.  Primary  Input  Data 

(1)  HIMAD  and  10MAD  Surf ace-to-Ai r  Missile  (SAM)  fire  unit  locations, 

(2)  Detection/tracking/engagement  envelopes  for  SAM  units, 

(3)  Warsaw  Pact  aircraft  attrition  rates  due  to  SHORAD  units, 

(4)  Missile  inventories  and  resupply  rates, 

(5)  Threat  assessment  criteria  (single,  few,  many  hostile  aircraft), 

(6)  Fi ri ng  doctri ne  (e.g.,  shoot-shoot-look), 

(7)  Crew/system  response  times, 

(8)  Probability  of  detection  of  air  targets, 

(9)  Probability  of  kill  of  air  targets  by  SAM  type, 

(10)  Azimuth  limits  (patriot)  and  dead  zones,  and 

(11)  Operational  availability  of  SAM  units  is  addressed  by  randomly 
withholding,  by  use  of  a  random  number  generator,  appropriate 
numbers  and  types  from  model  input. 

b.  Surface-to-Air  Capabilities 

Early  warning  radars  and  fire  units  provide  threat  data  to 
CRC's.  Detection  ranges  are  based  on  radar  1  i ne-of-si ght  with  both  earth 
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curvature  and  terrain  masking  considered.  A  threat  can  be  masked  and 
remasked  from  a  fire  unit  based  on  terrain  elevations  specified  for  every 
25  km  hexagonal  area.  Probability  of  detection  is  a  function  of  range. 

CRC's  assign  flight  tracks  to  BOC's.  BOC's  assign  tracks  to 
fire  units  depending  upon  the  availability  of  the  battery  to  engage  the 
flight.  Fire  units  have  the  ability  to  detect  hostile  tracks  directly  if 
undetected  through  the  CRC.  All  targets  have  the  same  priority  for  attack 
(e.g.  ,  first  seen,  first  attacked)  except  that  incoming  targets  are 
attacked  before  outgoing  targets.  Priorities  are  established  when  fire 
units  are  operating  in  an  autonomous  mode. 

MADEM  determines  if  the  threat  flight  is  within  a  three 
dimensional  engagement  envelope  of  a  fire  unit  and  if  the  flight  has  been 
detected.  If  both  answers  are  yes,  then  MADEM  schedules  a  "fire"  and  an 
engagement  occurs.  Launching  sequences  are  based  on  crew/system  reaction 
times  and  firing  doctrine.  Once  an  engagement  has  begun,  it  can  not  be 
interrupted  (e.g.,  for  masking  problems).  The  firing  doctrine  for  a  HAWK 
fire  unit  is  shoot-shoot-look  on  the  first  engagement  unless  there  are  less 
than  nine  missiles  remaining  on  site.  On  subsequent  engagements  of  if  less 
than  nine  missiles  remain  at  the  fire  unit  the  doctrine  changes  to  shoot- 
look-shoot.  The  Patriot  system  has  the  capability  of  firing  multiple 
simultaneous  missions. 

SHORAD  Mre  units  are  implicitly  modeled;  they  cause 
attrition  of  hostile  flights  uniformly  over  all  NATO  territory. 

Nike  Hercules,  HAWK,  and  Patriot  units  are  resupplied  with 
missiles  in  accordance  with  prescribed  resupply  rates. 

Figure  1 1 1 - 7  illustrates  two  MADEM  generated  formations  with 
HAWK  engagements. 

c.  Surface-to-Air  Data  Output 

(1)  Number  of  aircraft  detected  and  acquired, 

(2)  Number  of  missiles  fired, 

(3)  Number  of  aircraft  destroyed. 
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MADlM  Generated  Ground-to-Air  Engagement 


5. 
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Command,  Control  and  Communications  (C  ) 

a.  Primary  Input  Data 
3 

(1)  C  relationships  and  location  of  nodes, 

(2)  Primary  Target  Lines  (PTL)  for  SAM  units,  and 

(3)  Probability  of  mi s i denti fyi ng  a  flight  of  aircraft 

b.  C3  Capabilities 

For  the  base  case,  the  highest  state  of  air  defense  alert  is 
assumed.  That  is,  air  defense  elements  are  in  Emergency  Defense  Positions 
(EDP)  and  the  appropriate  degree  of  readiness  of  each  available  system  has 
been  achieved. 

The  base  case  plays  a  CRC  mode  of  control.  This  means  the 
CRC  receives  threat  data  from  early  warning  radars  and  fire  units  and 
assigns  targets  to  air  bases  and  interceptors  or  to  SAM  BOC's  and  fire 
units.  Fire  units  may  be  at  battery  level  in  the  case  of  Nike  Hercules,  or 
at  platoon  level  in  the  case  of  HAWK  and  Patriot.  In  this  mode  of  control 
the  CRC  does  not  coordinate  with  other  CRC's  and  hence  it  is  possible  that 
two  or  more  CRC's  may  assign  different  air  defense  elements  the  mission  of 
attacking  the  same  target  at  the  same  time.  If  a  fire  unit  can  not  engage 
an  assigned  flight,  a  message  is  sent  to  the  BOC  and  hence  to  the  CRC  so 
stating.  The  target  is  then  reassigned  by  the  CRC.  No  alternate  com¬ 
munication  routings  are  possible.  Message  traffic  is  delayed  four  (4) 
seconds  for  each  transmission.  Reference  Figure  1 1 1 - 8 . 

The  present  state  of  MADEM  does  not  permit  explicit  modeling 
of  various  Weapons  Engagement  Zones  (WEZ)  because  of  the  complex  geometry 
involved.  A  modified  WEZ  is  played,  however,  by  prohibiting  HIMAD  units 
from  firing  at  targets  below  a  specified  altitude  where  probability  of  kill 
is  less  and  by  prohibiting  LOMAD  units  from  firing  at  targets  above  a 
specified  altitude  regardless  of  geographical  locations  of  fire  units. 
Interceptors  operate  anywhere  as  directed  by  the  CRC. 

Minimum  burst  altitudes  are  prescribed  for  various  yield 
nuclear  SAM  warheads. 

Imperfect  identification  is  played.  Once  a  hostile  target 
is  mi s identi f i ed  it  can  be  correctly  identified  at  a  later  time  by  inter¬ 
ceptors  at  time  of  engagement.  Subsequently,  the  CRC  may  correct  its 
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misperception.  Mi  sidenti f ication  of  friendly  aircraft  may  be  corrected 
only  if  the  aircraft  has  not  been  assigned  to  a  SAM  unit. 

AWACS  can  detect  hostile  flights  and  vector  fighter  inter¬ 
ceptors  but  is  not  attacked  by  hostile  flights.  No  NATO  aircraft  are 
dedicated  to  AWACS  defense. 

Air  defense  units  assume  the  highest  state  of  alert  and 
revert  to  autonomous  operations  when  communications  to  higher  organizations 
are  lost.  This  can  occur  when  a  CRC  or  BOC  has  been  neutralized  by  hostile 
flights  or  when  the  effects  of  Electromagnetic  Pulse  (EMP)  destroys  com¬ 
munications  equipment.  For  SAM  fire  units,  priorities  for  engagement  are 
to  flights  approaching  along  the  unit's  primary  target  line,  to  all  other 
incoming  flights,  and  finally  to  outgoing  flights.  For  air  base  defense,  a 
flight  of  interceptors  is  scrambled  to  one  of  seven  (randomly  selected) 
hexagons  adjacent  to  the  airbase  by  a  "dummy  CRC".  When  a  hostile  flight 
is  detected  by  the  airborne  flight,  the  "dummy"  CRC  scrambles  all  available 
flights  to  adjacent  hexagons  where  air-to-air  battle  ensues  in  accordance 
with  target  of  opportunity  rules  of  engagement.  The  dummy  CRC  lands  the 
interceptors  when  the  threat  has  passed. 

6.  Electronic  Warfare  (EW) 

a.  Primary  Input  Oata 

Degraded  detection  and  engagement  ranges. 

b.  EW  Capabi 1 i ties 

In  an  EW  environment,  MADEM  degrades  the  operational  charac¬ 
teristics  of  all  NATO  air  defense  units  uniformly  across  the  defended  area 
by  type  system.  The  worst  electronic  countermeasure  threat  for  each  type 
system  is  used  to  degrade  the  performance  of  the  system.  Frequency  and 
power  characteristics  of  jammers  are  considered  in  arriving  at  the  degraded 
performance  characteristics  of  NATO  air  defense  units. 

7.  Nuclear  Environment 

a.  Primary  Input  Data 

(1)  Criteria  (size/altitude  of  threat  flights  and  minimum  normal 
burst  altitude)  for  the  CRC  to  make  assignments  of  nuclear 
weapons  by  type  warhead,  and 

(2)  Probability  of  kill  of  nuclear  air  defense  weapons. 
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Nuclear  air  defnese  missiles  are  employed  based  on  a  logic 
criteria  that  considers  threat  size,  altitude,  and  Minimum  Normal  Burst 
Altitude  (MNBA).  It  is  assumed  that  separation  distances  between  aircraft 
flying  above  MNBA  are  such  that  a  nuclear  burst  will  destroy  at  most  a 
single  plane. 

When  a  nuclear  burst  occurs,  all  communications  within  the 
same  hexagon  as  the  burst  are  disabled  for  the  duration  of  the  raid(s).  If 
communictions  are  lost  in  this  manner,  subordinate  units  operate  in  an 


autonomous  mode. 
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SECTION  IV 

MODEL  SPECIFICATIONS 


A.  INTRODUCTION 

This  chapter  documents  the  basic  specifications  of  the  MADEM  simula¬ 
tion.  Its  purpose  is  to  explain  the  structure  and  assumptions  which 
underly  the  processes  modeled  in  MADEM.  While  this  chapter  deals  with  the 
processes  modeled  in  some  detail,  it  does  not  attampt  to  cover  the  actual 
implementation  of  the  model  in  the  FORTRAN  code.  Users  who  require  more 
detailed  information  on  model  implementation  are  referred  to  the  MADEM 
Programmer  Manual  and  Source  Li sti nqs . 

B.  SIMULATION  ARCHITECTURE 


1 .  Modul ari ty 

The  model  was  developed  along  functional  lines  so  that  each  major 
function  exists  as  a  semi-independent  section  of  the  model.  Each  major 
function  is  referred  to  as  a  module.  The  modules  are  further  divided  into 
smaller  segments  each  of  which  contains  the  logic  for  a  single  decision  or 
physical  operation. 

Each  function  represents  some  specific  air  activity  or  event. 
For  example,  the  perceptions  of  enemy  aircraft  are  handled  in  a  module 
separate  from  the  module  that  makes  decisions  to  fire  on  those  aircraft. 
Within  the  perception  module  are  the  various  segments  such  as  the  one  that 
determines  line  of  sight  intervisibility  between  a  battery  radar  and  a 
fl ight  of  ai rcraft. 

The  various  segments  and  modules  of  the  model  are  tied  together 
through  a  centralized  software  control  system  that  manages  the  overall 
functioning  of  the  model.  This  centralized  software  control  system,  in 
addition  to  providing  basic  data  processing  functions  such  as  input  and 
output  control,  provides  the  sophisticated  list  processing  technique  which 
is  the  basis  for  much  of  the  power  of  the  MADEM  architecture.  Module 
^unctions  are  summarized  in  Table  IV- 1 . 


35 


TABLE  IV-1.  MADEM  MODULE  SUMMARY 


MODULE/CONTROL  ROUTINE 

ASSIGN 

ATTACK 

COMMO 

DOGFITE 

FLY 

NAYBOR 

PERCEPT 

PLAN 

PONDER 

TOWER 

UMPIRE 


FUNCTION 

Combat  reporting  center  makes  assignments 
of  interceptors  to  Red  flights. 

Carry  out  ground  attack  by  Red  flights. 

Communications  transmission 

Surface-to-air  missile  engagement  decisions 

Aircraft  movement 

Determine  nearby  units  &  schedule  all  units 
for  a  chance  to  "see"  an  action. 

Controls  perception  of  other  units. 

Red  threat  planning 

Unit  information  processing. 

Air  base  operations 

Determines  outcome  of  missile  launches. 
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Discrete  Events 

MADEM  is  a  player  centered,  discrete  event  simulation.  The 
simulation  is  made  up  of  three  fundamental  components  -  entities,  actions 
and  processes.  Entities  are  the  units  which  actually  participate  in  battle 
as  active  players.  These  player  units  may  take  actions  which  affect  their 
environment  including  other  units.  The  processes  simulated  in  MADEM  are, 
in  fact,  composed  of  many  discrete  actions  taken  by  entities  interacting 
with  each  other  in  the  battle  area  over  time.  Units  take  actions  in 
response  to  their  perception  of  the  environment.  When  an  action  is  taken 
the  unit  schedules  an  event  or  series  of  events  which  corresponds  to  the 
action  to  occur  some  time  in  the  future  of  the  battle.  The  time  between 
the  decision  to  take  an  action  and  the  scheduled  time  of  the  event  reflects 
the  time  lag  inherent  in  the  action  being  taken. 

Each  player  must  schedule  many  events  in  the  course  of  the  simu¬ 
lation.  As  a  result,  the  number  of  events  that  must  be  managed  by  the 
simulation  in  a  typical  scenario  is  quite  large.  For  example,  an  average 
MADEM  historical  tale  contains  over  240  events  for  each  second  of  battle. 
The  interaction  for  these  events  is  controlled  by  the  Simulation  Control 
Software  (SCS).  The  SCS  sorts  all  scheduled  events  to  insure  a  logical 
progression  of  events.  It  also  interprets  the  events  as  they  occur  in  the 
sequence  of  battle  and  activates  the  appropriate  software  module  to  simu¬ 
late  the  desired  processes.  When  a  player  unit  is  destroyed  or  incapa¬ 
citated  to  the  point  where  its  future  events  cannot  be  expected  to  occur, 
the  SCS  withdraws  the  unit's  future  events  from  the  schedule. 

3.  Action  Cycle 

Model  processes,  as  represented  by  the  software  modules  listed  in 
section  II-B-1,  are  driven  by  a  three  phase,  player  centered,  action  cycle. 
Figure  IV- 1  illustrates  this  cycle.  The  cycle  is  initiated  by  an  action 
taken  by  a  player  unit.  The  initiating  action  is  usually  a  movement. 
However,  other  actions  including  attacks,  deaths  and  messages  may  also 
initiate  the  cycle.  These  initiation  actions  are  then  perceived  by  player 
units  through  their  respective  acquisition  and  communications  devices.  The 
nature  and  status  of  the  units  acquisition  and  communications  aevices  will 
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determine  the  extent  to  which  perceptual  data  is  distorted.  For  example, 
it  is  possible  for  interceptors  to  incorrectly  identify  a  Blue  flight  as  a 
Red  f 1 ight. 

Perceptual  data  is  then  pondered  to  determine  the  appropriate 
action  for  the  perceiving  unit  to  take.  The  ponder  phase  of  the  cycle  is 
analogous  to  a  units  consideration  of  actions  to  be  taken  in  response  to 
external  events.  The  time  a  unit  requires  to  ponder  and  react  to  percep¬ 
tions  varies  with  the  unit  type  and  the  complexity  of  the  action  perceived. 
Actions  resulting  from  the  ponder  phase  reinitiate  a  new  cycle. 

4.  Units  Represented 

Two  types  of  units  are  explicitly  represented  in  MADEM  player 
units  and  non-player  units.  Player  units  actively  participate  in  the 
battle  while  non-player  units  act  as  passive  targets  for  Red  attacks.  All 
units  may  be  targeted.  However,  only  active  players  may  initiate  or 
respond  to  attacks.  Figures  IV-2  and  IV-3.  illustrate  the  Blue  and  Red 
command  structures  modeled  in  MADEM.  Valid  player  and  target  types  are 
1  isted  in  Appendix  E. 

Combat  Reporting  Centers  (CRC)  are  the  highest  ranking  active 
player  on  the  Blue  side.  Although  the  Allied  Tactical  Airforce  (ATAF)  and 
Sector  Operations  Center  (SOC)  command  levels  are  represented,  their  func¬ 
tions  in  the  current  version  of  the  model  are  implicit.  They  act  only  as 
conducts  for  communication  between  combat  reporting  centers  (CRC)  within 
the  model  software.  Enhancements  currently  under  development  would  result 
in  the  ATAF  and  SOC's  becomming  active  participants  in  the  allocation  of 
Blue  air  defenses . 

The  Red  Theater  Commander  (RTC)  is  the  highest  ranking  active 
player  on  the  Red  side.  It  is  responsible  for  allocation  of  Red  penetrator 
flights  to  appropriate  targets.  Since  the  Red  side  is  never  attacked  by 
Blue,  the  Red  command  structure  does  not  include  defensive  units  such  as 
battalion  operations  centers  (BOC)  and  surface-to-ai  r  missile  batteries 
(BTRY). 


4368/7  9W 


Figure  IV -2 . 


Blue  Command/Control  Structure 
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Figure  IV-3.  Red  Command/Control  Structure 
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C.  DEFINITIONS  OF  PLAYERS 

1 .  Combat  Reporting  Centers  (CRC) 

The  combat  reporting  centers  are  the  highest  ranking  active 
player  on  the  81ue  side.  CRC's  control  the  actions  of  all  subordinates 
which  are  capable  of  communication  with  the  CRC.  The  CRC's  are  responsible 
for  acquisition  and  identification  of  threat  aircraft  within  their  zones  of 
control.  They  are  also  responsible  for  allocation  of  defense  units  to 
incoming  Red  penetrators. 

In  the  course  of  fulfilling  these  responsibilities  the  CRC  units 
perform  the  following  functions: 

(1)  Acceptance  of  early  warning  information 

(2)  Determination  of  type  of  subordinate  to  engage  threats 

(3)  Request  of  interceptor  launch  by  air  bases 

(4)  Assignment  of  threats  to  specific  subordinates 

(5)  Receipt  and  processing  of  engagement  status  information  from 
subordinates 

(6)  Vectoring  of  interceptors  to  assigned  threats 

2.  Red  Theater  Commander  (RTC) 

The  Red  theater  commander  (RTC)  is  the  highest  ranking  active 
player  on  the  Red  side.  The  RTC  is  the  core  of  the  Red  Threat  planning 
process.  It  interprets  general  attack  specifications  input  by  the  user  and 
converts  them  to  a  set  of  specific  flight  plans  which  are  used  to  carry  out 
the  attacks.  The  RTC  controls  execution  of  waves  and  raids  as  well  as  the 
channeling  of  penetrator  flights  through  appropriate  corridors.  In 
addition,  the  RTC  chooses  specific  targets  to  be  attacked  based  on  target 
location,  damage  level  and  available  aircraft  types. 

In  the  course  of  fulfilling  these  responsibilities  the  RTC  per¬ 
forms  the  following  functions: 

(1)  Interprets  user  input  attack  specifications 

(2)  Perceives  location  and  damage  level  of  potential  targets.  (Red 
perceptions  may  differ  from  reality) 
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(3)  Constructs  general  resource  limits  tor  each  wave  and  raid. 

(4)  Oefines  specific  formation  components 

(5)  Determines  takeoff  times  for  flights  which  make  up  the  formations 

(6)  Sets  flight  plans  (including  rendezvous  points)  for  each  flight. 

(7)  Allocates  flights  to  specific  targets 

3.  Air  Bases  (AB) 

Air  bases  are  the  on-^  player  unit  type  used  by  both  the  Red  and 
Blue  sides.  Both  Blue  and  Red  air  bases  are  capable  of  keeping  track  of 
the  number  and  type  of  aircraft  on  the  air  base  as  well  as  the  status  of 
each  aircraft  type  in  terms  of  launch  capability. 

Air  bases  perform  the  following  functions: 

(1)  Accept  launch  requests  from  CRC  or  RTC. 

(2)  Launch  available  aircraft  on  request 

(3)  H_ Id  returning  aircraft  for  refueling,  rearming,  etc. 

(4)  Antonomous  launching  of  aircraft  to  CAP  orbit  when  not  under 
control  of  a  CRC.  (Blue  only) 

4.  Battalion  Operations  Centers  (BQC) 

Battalion  operations  centers  (BOC)  exist  only  on  the  Blue  side. 
BOC's  report  to  CRC's  and  commas  surface-to-ai r  batteries.  BOC's  are 
responsible  for  coordinating  assignment  of  incoming  Red  targets  to  SAM 
batteries  under  their  command.  They  are  also  responsible  for  monitoring 
engagements  and  reporting  results  to  the  CRC.  Three  types  of  BOC  are 
currently  simulated:  HAWK,  NIKE-HERCULES  and  PATRIOT. 

In  the  course  of  fulfilling  these  responsibilities  the  BOC's 
perform  the  following  functions: 

(1)  Acquisi tion/IFF  of  threat  aircraft 

(2)  Acceptance  and  passage  of  early  warning  information  to  the  CRC. 

(3)  Providing  engagement  status  reports  to  the  CRC. 

(4)  Acceptance  of  penetrator  assignments  from  the  CRC 

(5)  Digestion  of  information  on  assigned  threats  and  scheduling  of 
subordinates'  engagements. 

(6)  Prioritization  of  threats 
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(7)  Assignment  of  threats  to  particular  batteries 

(8)  Receipt  and  processing  of  engagement  and  battery  status  reports 
from  subordi nates 

(9)  Antonomous  selection  of  threats  for  engagement,  when  not  under 
control  of  CRC 

5.  Batteries  (BTRY) 

Surface-to-Ai r  batteries  (BTRY)  exist  only  on  the  Blue  side. 
BTRY's  report  to  BOC's  and  are  composed  of  multiple  time  units.  BTRY's  are 
the  lowest  ranking  active  player  on  the  Blue  side.  BRTY's  perform  the 
fol lowing  functions: 

(1)  Acquisi tion/IFF  of  threat  aircraft 

(2)  Passage  of  early  warning  information  to  BOC 

(3)  Acceptance  of  assignments  from  BOC 

(4)  Providing  engagement  and  battery  status  reports  to  BOC 

(5)  Digestion  of  information  on  assigned  threats 

(6)  Allocation  of  fire  units  to  engage  threats 

(7)  Reloading  and  request  for  resupply 

(8)  Autonomous  operation  when  not  under  control  of  BOC. 

6.  Aircraft  Flights  (FLT) 

Flights  (FLT)  are  the  basic  maneuver  unit  in  MADEM.  They  exist 
on  both  the  Blue  and  Red  sides.  Flights  consist  of  one  or  more  aircraft  of 
the  same  type  launched  from  the  same  air  base.  qhts  are  unique  in  that 
they  are  temporary  entities.  In  response  to  an  order  from  a  CRC  or  RTC  an 
air  base  constructs  a  flight  of  the  requested  type  from  the  available 
aircraft  on  base.  Upon  launch  a  new  flight  entity  is  created.  This  entity 
acts  as  a  player  unit  in  the  battle  until  it  is  either  destroyed  or  returns 
to  base.  While  the  flight  is  airborne  it  reports  directly  to  the  CRC  that 
commands  its  originating  air  base.  When  the  flight  returns  to  base  it 
ceases  to  exist  as  a  separate  player  entity  and  its  component  aircraft  are 
returned  to  the  air  base's  pool.  While  airborne,  flights  perform  the 
following  functions: 

(1)  Move  on  a  9.45  km  hexagonal  coordinate  system. 


(2)  Fly  a  sequence  of  straight- 1 ine  segments 

(3)  Rendezvous  with  other  flights  to  form  formations  which  proceed 
against  assigned  targets 

(4)  Perform  maneuvers  at  checkpoints  between  flight-path  segments, 
possible  maneuvers  include: 

•  change  direction 

•  change  velocity 

•  initiate  altitude  change 

(5)  Check  fuel  on  each  move  and  head  home  when  supply  is  low. 

(6)  Each  movement  of  a  flight  results  in  a  new  opportunity  for  other 
players  to  acquire  and  identify  it. 

D.  NON-PLAYERS 

In  addition  to  the  player  units  described  in  the  previous  section, 
MADEM  also  contains  a  variety  of  non-player  units.  These  Blue  units  are 
non-players  in  the  sense  that  they  act  only  as  targets  for  Red  attacks. 
These  passive  target  units  may  be  used  to  represent  a  wide  variety  of 
significant  penetrator  targets  which  have  no  active  air  defense  capability. 
A  complete  listing  of  non-player  unit  types  is  contained  in  Appendix  E. 

E.  DETAILED  PROCESSES 

1 .  Red  Threat  Planning 

a.  Planning  Process  Overview 
1 )  Red  Attack  Structure 

The  Red  Attack  is  carried  out  in  a  series  of  raids  each 
of  which  is  made  up  of  a  number  of  waves.  Raid  and  wave  start  times  are 
generally  sequential  and  result  in  an  attack  structure  similar  to  Figure 
IV-4.  Each  raid  and  its  component  waves  are  planned  by  matching  formation 
and  targeting  requirements  with  air  base  and  corridor  locations.  Subse¬ 
quent  raids  are  based  upon  Red  aircraft  attrition,  new  targeting  require¬ 
ments,  and  perceptions  of  damage  caused  by  previous  raids.  Figure  IV- 5 
illustrates  a  simple  MADEM  scenario. 
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Figure  I V - 4 .  Red  Attack  Structure 
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The  basic  maneuver  unit  in  MAOEM  is  the  "Flight".  Each 
flight  consists  of  aircraft  of  the  same  type  scheduled  against  a  specific 
target.  Flight  types  consisting  of  specified  numbers  of  aircraft  are 
assigned  to  formation  types  by  the  user.  (Figure  I V- 6 ) .  Individual  air¬ 
craft  are  not  tracked.  However,  they  are  accounted  for  when  the  flight  is 
attacked  and  aircraft  kills  result. 

Flights  are  assembled  from  aircraft  located  on  the  air 
bases.  Each  air  base  keeps  track  of  the  number  and  type  of  aircraft  on  the 
base.  All  bases  have  user  specified  recovery  to  launch  delay  times  asso¬ 
ciated  with  aircraft  types  which  determine  the  rate  at  which  flights  can  be 
launched.  Only  complete  flights  may  be  launched.  If  there  are  insuf¬ 
ficient  aircraft  on  the  base  to  assemble  a  desired  flight  type,  the  flight 
is  not  launched  and  the  aircraft  remain  on  the  base  as  surplus  for  the  next 
raid. 

Flights  launched  from  the  air  bases  rendezvous  to  form 
formations.  Formation  types  are  assigned  to  attack  various  target  types  by 
the  user.  Individual  formations  are  assigned  to  attack  individual  targets 
by  the  PLAN  module.  Formations  launched  during  the  same  specified  time 
period  constitute  a  wave. 

Waves  pass  through  user  specified  attack  corridors  and 
attack  scheduled  targets  within  bounds  prescribed  by  the  user  (e.g., 
maximum  and  minimum  ranges,  type  targets,  corridor  "spread  angles"  and 
"boundaries").  Figure  IV-7  illustrates  a  typical  corridor.  Normally  these 
corridors  will  be  cleared  of  Blue  SAM  batteries  by  the  first  Red  flights 
entering  the  corridor.  Flights  change  course  to  negotiate  passage  through 
corridors  and  thereafter  follow  a  piecewise  linear  course  to  their  target 
and  return  to  home  base.  Flights  also  change  altitude  during  their 
missions  in  accordance  with  user  input  mission  profiles.  If  a  flight  fails 
to  detect  its  assigned  target,  there  is  no  opportunity  to  search  for  other 
targets  and  the  flight  returns  to  home  base  without  inflicting  damage. 
Flights  report  percieved  target  damage  which  is  used  for  subsequent  strike 
scheduling.  Figure  IV-8  illustrates  a  typical  mission  profile. 
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Figure  IV-6. 
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2)  The  Planning  Cycle 

The  cyclical  threat  planning  process  used  by  MADEM  is 
illustrated  in  Figure  I V- 9 .  At  the  beginning  of  a  run  the  user  inputs  the 
specifications  for  each  raid  (listed  in  section  C.l.b).  Target  assignments 
and  corresponding  flight  orders  are  then  generated  by  the  PLAN  module 
subject  to  aircraft  resource  constraints.  After  the  initial  raid  has  been 
carried  out,  the  surviving  Red  aircraft  return  to  their  bases  and  report 
percieved  target  damage  levels  to  the  PLAN  module.  If  subsequent  raids 
have  been  specified  by  the  user,  the  PLAN  module  adjusts  target  priorities 
based  on  its  remaining  aircraft  resources  and  generates  new  target  assign¬ 
ments  and  flight  orders  for  the  next  raid.  Once  the  process  has  been 
initiated  by  user  inputs  the  planning  and  attack  process  is  self  contained. 
All  subsequent  raids  will  be  carried  out  without  user  intervention. 

3)  Planning  Stages 

Red  threat  planning  is  carried  out  in  four  major  stages 
which  may  be  summarized  as  follows: 

(1)  Corridor  Boundary  Specification  -  Attack  corridors  must  be. 

respecified  for  each  raid. 

(2)  Overall  Resource  Allocation  -  User  specified  formation  to  target 
type  assignments  are  compared  to  available  formations  by  type. 
Assignments  are  proportional ly  adjusted  to  account  for  descrep- 
ancies  between  user  specified  requirements  and  available 
resources  for  each  raid. 

(3)  Target  Assignment  -  Individual  formations  are  assigned  to 

specific  targets  based  on  formation,  availability  and  specific 
target  selection  criteria  for  each  wave. 

(4)  FI ight  Schedul i nq  -  Orders  for  specific  flights  to  join  forma¬ 
tions  and  attack  specific  targets  are  generated  for  each  wave. 

These  orders  include  launch  times  and  mission  profiles. 

Each  of  these  stages  is  composed  of  a  number  of  steps.  The  detailed 
operation  of  each  stage  is  discussed  in  the  following  sections  -  C.l.d, 
C. 1 . e,  C. 1 . f ,  and  C. 1 . g. 
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Figure  IV-9.  The  Red  Threat  Planning  Cycle 


b. 


Corridor  Boundary  Specifications 

Attack  corridors  must  be  specified  by  the  user  for  each 
raid.  Required  inputs  for  each  corridor  include  the  corridor  limit  loca¬ 
tions,  corridor  heading,  spread  angle,  and  buffer  zone  width.  The  rela¬ 

tionship  of  these  inputs  to  a  hypothetical  attack  corridor  is  illustrated 
in  Figure  IV- 10. 

Processing  of  these  corridor  specifications  by  the  plan 
module  results  in  creation  of  a  set  of  geographic  zones  for  each  corridor. 
These  zones,  which  are  illustrated  in  Figure  I V- 11,  are  used  in  the  target 
assignment  stage  of  planning  to  determine  the  geographic  suitability  of 
specific  targets.  All  targets  in  zones  1  and  4  are  acceptable,  while 
targets  in  zone  0  are  unacceptable.  HAWK  batteries  located  in  zones  2  and 
3  are  acceptable.  However,  all  other  targets  in  zones  2  and  3  are 

unacceptable.  The  purpose  of  this  target  classi  f ication  scheme  is  to 
insure  that  the  corridor  and  its  buffer  zones  are  cleared  of  Blue  units 

which  can  shoot  into  the  corridor  center. 

c*.  Overall  Resource  Allocation 

The  total  available  aircraft  resources  are  allocated  to  user 
specified  target  types  for  each  raid.  This  process  attempts  to  reconcile 
any  descrepancies  between  the  attack  resource  assignments  for  each  target 
type  input  by  the  user  with  actual  resources  available.  This  stage  of  the 
planning  process  is  carried  out  in  the  following  three  steps: 

(1)  Determine  for  each  wave  the  number  of  aircraft,  flights  and 
formations  required  to  attack  all  of  the  target  types  specified 
by  the  user. 

(2)  Match  each  air  base  to  the  closest  attack  corridor  and  calculate 
the  number  of  aircraft  (by  type)  available  on  each  base. 
Determine  the  total  number  of  aircraft  available  to  assemble 
flights  and  formations. 

(3)  If  the  potential  target  is  acceptable,  an  available  formation  is 
assigned  to  attack  it  in  the  current  wave.  If  it  is  not  accept¬ 
able,  step  (1)  is  repeated  and  a  new  potential  target  is  examined 
for  geographic  suitability. 
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Execution  of  these  three  steps  for  all  available  formations  results  in  a 
list  of  formation  to  target  assignments,  each  formation  is  then  assembled 
from  flights  launched  from  the  airbases.  Although  all  of  the  flights  in  a 
formation  are  assigned  to  attack  the  same  target,  their  individual  mission 
profiles  may  vary  considerably.  This  variation  is  particularly  pronounced 
for  flights  originating  at  different  airbases  which  must  rendevous  to  form 
a  formation.  The  process  of  flights  and  their  corresponding  mission  pro¬ 
files  is  carried  out  in  the  Flight  Scheduling  Stage, 
d.  FI iqht  Schedul ing 

Flight  scheduling  is  the  last  stage  in  the  Red  Threat 
Planning  Process.  It  is  performed  for  each  wave  in  the  current  raid  and 
consists  of  generating  a  series  of  orders  for  each  flight  required  to  make 
up  the  formations  specified  in  the  target  assignment  stage.  Flight 
scheduling  is  a  two  step  process  which  may  be  summarized  as  follows: 

(1)  Determine  the  rendevous  point  for  each  formation.  The  rendezvous 
point  is  calculated  as  the  center  of  gravity  of  the  air  bases 
weighted  by  the  number  of  aircraft  in  the  flights  to  be  launched 
from  each  base. 

(2)  Construct  a  series  of  orders  for  each  flight  which  instruct  it  on 

the  actions  to  be  carried  out  at  specified  locations.  These 

orders  cause  the  flight  to  climb  to  its  rendezvous  point,  wait 
for  other  flights  in  the  formation,  proceed  to  the  target  through 
the  corridor,  carry  out  the  attack  and  return  to  base.  A  flight 
profile  of  this  type  is  shown  in  Figure  IV-8.  Altitudes  at 

various  phases  in  the  mission  are  specified  by  the  user  in  the 
f 1 ight  data  base. 

(3)  If  a  discrepancy  exists  between  the  required  and  available  air¬ 
craft,  the  allocation  of  formation  types  to  target  types  is 
proportional ly  adjusted  accross  target  types  until  the  actual 
number  of  formations  assigned  equals  the  number  available. 

Execution  of  these  three  steps  results  in  a  set  of  maximum  aircraft 

allocations  for  each  formation  and  target  type.  These  maximum  allocations 
are  then  used  to  guide  the  Target  Assignment  Stage. 
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e.  Target  Assignment 

An  assignment  of  formations  to  specific  targets  is  made  for 
each  wave  in  the  current  raid.  Assignments  are  made  subject  to  the  maximum 
allocation  constraints  which  were  calculated  in  the  Overall  Resource  Allo¬ 
cation  Stage.  Target  assignments  are  made  in  a  three  step  process  which 
considers  formation  type  availability  and  target  selection  criteria.  This 
process  may  be  summarized  as  follows: 

(1)  For  each  available  formation  examine  the  perceived  damage  level 
of  potential  Blue  targets.  Potential  targets  are  stratified  by 
types  which  are  matched  to  formation  types  specified  by  the  user. 
The  number  of  formations  available  by  type  has  already  been 
determined  in  the  resource  allocation  stage.  Only  targets  of  the 
proper  type  are  examined. 

(2)  Select  the  least  damaged  potential  target  and  determine  its 
geographic  suitability.  Suitability  is  determined  relative  to 
the  closest  attack  corridor  and  the  Red  air  bases  to  which  the 
corridor  has  been  matched  in  the  resource  allocation  stage.  In 
order  to  be  acceptable,  a  potential  target  must  be  within  minimum 
and  maximum  range  and  be  located  within  the  corridor  zones  set  in 
the  corridor  boundary  specification  stage,  (see  figure  08). 

Execution  of  these  steps  for  each  formation  which  has  an  assigned  target 
completes  the  four  stage  planning  process.  All  flights  now  have  their 
orders  and  are  ready  to  carry  out  the  raid  without  further  intervention 
from  the  plan  module. 

2.  Aircraft  Movement 

a.  Terrain  Representation 

The  aircraft  movement  process  in  MADEM  is  the  principal 
driver  of  simulation  events;  once  an  attack  is  set  in  motion,  the  dynamic 
parallel/serial  reactions  of  defenders  are  scheduled  based  primarily  on 
events  related  to  the  position  and  movement  of  penetrating  aircraft. 
Terrain  in  MADEM  is  represented  on  a  discrete,  two  dimensional  geographic 
coordinate  system  whose  points  represent  centers  of  hexagonal  regions.  The 
lowest  level  (smallest)  hexes  currently  represented  in  MADEM  are  9.45  km 
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from  center  to  center;  this  is  the  basic  resolution  or  level  of  uncertainty 
in  the  actual  position  of  aircraft.  Appendix  A  discusses  the  hex  coordi¬ 
nate  system  in  more  detail.  Aircraft  altitude  in  MADEM  is  represented  on  a 
continous  coordinate  defined  from  local  terrain  altitude;  local  terrain 
altitude  is  currently  defined  for  second  level  hexes,  which  are  25  km  from 
center  to  center.  The  choice  of  terrain  resolution  has  to  date  been 
dictated  by  the  objectives  of  minimizing  memory  requirements  for  model 
execution  while  retaining  the  capability  to  represent  the  entire  central 
region  of  NATO's  European  theater.  Figure  IV- 1 2  depicts  the  hex  rela¬ 
tionships  of  terrain  representation  and  coordinates  in  MADEM. 

b.  Movement  Mechanics 

Aircraft  movement  takes  place  with  3  degrees  of  freedom; 
however,  there  is  no  representation  of  aerodynamic  constraints  on  aircraft 
motion.  Flight  paths  consist  of  straignt  line  segments  from  hex  center  to 
hex  center;  aircraft  altitude  changes  are  linear  with  respect  to  hexes 
traversed.  Aircraft  move  at  two  nominal  speeds  in  MADEM,  "cruise"  and  "air 
combat";  both  speeds  are  effective  ground  speeds  and  are  user  input  for 
each  flight  type.  Because  of  anisotropism  introduced  by  hex  topology,  path 
lengths  in  the  hex  system  are  not  necessarily  equivalent  to  cartesion 
distances.  Figure  IV- 1 3  shows  an  example;  flight  path  A  begins  from  the 
origin  0  and  traverses  10  hexes,  or  94.5  km  in  the  hex  coordinate  system. 
Flight  path  B  also  terminates  94.5  km  from  the  origin  0;  however,  flight 
path  B  traverses  12  hexes,  or  113.4  km  in  the  hex  coordinate  system.  In 
order  to  deal  with  this  problem,  "hex"  velocity  for  a  flight  of  aircraft  is 
increased  by  an  amount  directly  proportional  to  the  additional  distance  (if 
any)  traveled  in  the  hex  coordinate  system.  For  the  example  case  in  the 
figure,  the  nominal  "cartesian"  speed  along  flight  path  B  is  increased  by 
(113.4/94.5)  or  a  factor  of  1.20. 

c.  Formation  Structure 

Aircraft  movement  in  MADEM  occurs  for  "formations"  and 
"flights"  of  aircraft;  formations  can  consist  of  multiple  flights  which  in 
turn  consist  of  one  or  more  aircraft  of  a  generic  class.  Four  generic 
classes  are  represented:  interceptors,  (i.e. ,  defensive  air-air  systems); 
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penetrating  fighters  with  air-air  capabilities;  penetrating  fighter-bombers 
with  air-ground  and  optional  air-air  capabilities;  and  penetrating  bombers 
with  air-ground  capabilities  only.  Up  to  twenty  separate  types  of  aircraft 
can  be  represented  in  each  generic  class. 

Characteristics  of  aircraft  movement  processes  differ  some¬ 
what  between  interceptors  and  offensive  aircraft  flights.  Interceptor 
flight  paths  are  based  on  orders  from  a  CRC  to  a  flight  assigning  either  an 
orbit  station  near  the  CRC  or  a  hostile  flight  to  be  engaged.  Actual 
calculation  of  intercept  points  is  treated  in  the  discussion  of  air-air 
engagements;  however,  interceptor  flights  proceed  from  their  present  posi¬ 
tion  to  the  calculated  intercept  point  or  orbit  station  by  the  most  direct 
route  from  their  present  position.  Interceptor  flights  do  not  form  larger 
formations  or  maneuver  in  attacking  an  assigned  target;  for  example,  2 
flights  assigned  to  the  same  target  move  independently  to  the  calculated 
intercept  point,  as  shown  in  Figure  I V- 1 4 .  Figure  IV- 1 4  also  indicates  the 
segments  each  flight  would  traverse  in  moving  towards  its  objective. 

d.  Interceptor  Characteristics 

When  interceptor  flights  are  airborne  but  are  not  actively 
engaging  hostile  aircraft,  they  occupy  orbit  stations  positioned  nea^ 
either  their  commanding  CRC  or  their  home  air  base.  While  interceptor 
aircraft  are  orbiting,  they  are  assumed  to  remain  in  the  designated  orbit 
hex  at  a  fixed  altitude.  Multiple  flights  are  assumed  to  be  able  to  occupy 
the  same  orbit  station.  CRC's  position  orbiting  interceptor  flights 
randomly  within  hexes  adjacent  to  their  location;  air  bases,  when  auto¬ 
nomous,  orbit  interceptors  over  their  location. 

e.  Penetrator  Characteristics 

Penetrating  fighters,  fighter-bombers  and  bombers  flight 
paths  are  all  determined  in  the  planning  module.  The  planner  generates  a 
flight  path  consisting  of  a  series  of  straight  line  "legs".  Changes  in 
heading  and  altitude  are  arbitrary  between  legs,  allowing  operationally 
realistic  penetration  profiles  to  be  developed.  Penetrator  flights  move  on 
linear  segments  between  hex  centers  in  the  same  fashion  as  interceptors; 
however,  the  hex  centers  are  chosen  to  minimize  deviation  from  the  flight 
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plan  until  the  penetrator  reaches  its  target.  After  surviving  penetrators 
engage  their  targets  they  return  to  their  air  bases  by  the  most  direct 
route. 

f .  Movement  Constraints 

Flight  movements  for  all  aircraft  types  in  MADEM  are  con¬ 
strained  by  onboard  fuel.  Maximum  operating  ranges  for  each  type  aircraft 
are  input  by  the  user,  and  a  continuous  calculation  is  made  of  cumulative 
distance  traversed  by  each  flight.  At  the  initiation  of  each  flight  move¬ 
ment,  remaining  fuel  is  compared  against  the  distance  to  the  flight's  home 
base.  If  onboard  fuel  is  less  than  110%  of  the  distance  to  the  air  base, 
or  less  than  3  hex  equivalents,  the  flight  attempts  to  return  to  its  air 
base.  If  the  flight  is  engaged  by  other  aircraft  while  returning,  it  may 
expend  all  of  its  fuel  and  crash  short  of  its  airbase.  Fuel  consumption  is 
assumed  constant  for  all  speeds  and  altitudes;  however  flights  operating  in 
the  ground  attack  mode  (e.g. ,  fighter-bombers  and  bombers  engaging  their 
targets)  are  assessed  twice  the  normal  fuel  to  reflect  terminal  maneuvering 
for  attack. 

3.  Threat  Detection/Acquisition 

Threat  detection  and  tracking  processes  in  MADEM  are  initiated  by 
movements  of  both  friendly  and  hostile  flights  of  aircraft.  Each  movement 
of  a  flight  to  a  new  hex  location  invokes  a  search  for  all  other  players 
with  the  potential  ability  to  see  the  new  location  of  the  flight.  Each  of 
these  players  is  scheduled  for  an  opportunity  to  detect  the  flight. 

CRC's,  BOC's  and  batteries  can  all  perform  threat  detection. 
Each  specific  unit  has  one  or  more  acquisition  devices  associated  with  it, 
corresponding  to  the  acquisition  and  early  warning  radars  assigned  to  the 
unit.  All  radars  are  assumed  to  be  collocated  with  the  unit,  i.e.,  in  the 
same  9.45  km  hex;  user  specified  maximum  detection  ranges  for  a  nominal 
target  and  azimuth  search  sector  limits  (if  any)  are  also  specified  for 
each  radar. 

Three  basic  conditions  are  necessary  for  detection  to  occur: 

(1)  The  target  flight  must  be  inside  the  maximum  detection  range  for 
at  least  one  of  the  devices  associated  with  a  CRC,  BOC  or  battery 
which  can  see  to  the  location  of  the  flight; 


(2)  The  flight  must  be  within  the  azimuthal  scan  sector  for  the 
device; 

(3)  Radar  1 ine-of-sight  must  exist  from  the  acquisition  device  to  the 
target. 

In  the  event  that  a  target  flight  and  an  acquisition  unit  occupy 
the  same  hex,  immediate  acquisition  is  assumed.  Otherwise  the  maximum 
detection  range  for  any  device  associated  with  the  unit  is  considered. 
Figure  I V- 1 5  shows  the  probability  of  detection  curve  assumed  for  all 
devices  in  MADEM;  for  the  region  of  the  curve  where  detection  is  effec¬ 
tively  a  stochastic  event  (i.e.,  between  85%  and  100%  of  the  maximum 
detection  range)  a  single  replication  MONTE  CARLO  process  is  modeled.  For 
targets  which  are  successfully  detected,  a  test  is  made  on  azimuthal  scan 
limits  and  detection  events  are  nullified  unless  the  target  is  located  in 
the  scan  sector. 

For  cases  where  detection  can  occur  given  the  above  conditions, 
terrain  masking  to  the  acquisition  unit  is  tested.  The  line  of  sight 
calculation  assumes  a  curved  earth  and  utilizes  a  value  of  4/3  earth  radius 
to  account  for  radar  propagation  effects.  Terrain  masking  angles  are 
calculated  for  25  km  hexes  along  the  line  of  sight  from  the  detection  radar 
site  to  the  target;  these  are  compared  to  the  line  of  sight  angle  to 
determine  whether  masking  exists.  For  units  located  in  the  same  25  km  hex, 
line  of  sight  is  assumed  to  exist.  Figure  IV- 1 6  shows  a  schematic  example 
of  the  line  of  sight  calculation. 

Detection  events  in  MADEM  are  essentially  instantaneous  and  are 
scheduled  to  occur  at  the  same  time  that  a  flight  reaches  the  hex  location 
initiating  the  detection  event.  In  the  nonautonomous  (CRC)  mode  of 
operation,  detections  made  by  BOC's  and  batteries  are  passed  instan¬ 
taneously  to  the  commanding  CRC;  BOC's  operating  autonomously  conduct 
detection  independently  and  also  receive  track  information  instantly  from 
their  subordinate  batteries.  In  fully  autonomous  operation,  all  detections 
occur  at  the  battery  level. 

In  the  CRC  mode  of  control,  IFF  processing  is  assumed  to  occur  at 
the  CRC.  For  detections  made  by  the  CRC,  perfect  IFF  is  assumed.  Detec¬ 
tions  made  by  the  BOC's  and  batteries  are  passed  to  the  CRC  as  hostiles; 
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Figure  IV-16.  Line-Of-Sight  Determination 


the  CRC  then  detects  IFF  errors  of  the  type  where  hostile  aircraft  have 
oeen  declared  friendly  with  90%  probability.  When  operating  autonomously, 
BOC's  and  batteries  determine  the  identity  of  a  flight  based  on  a  single 
replication  MONTE  CARLO  process,  with  probability  of  correct  identification 
equal  to  97%.  The  identity  of  a  flight  is  determined  once  for  each  con¬ 
tinuous  engagement  of  that  flight;  only  flights  identified  as  hostile  are 
engaged. 

4.  Threat  A1 1 ocation 

a.  CRC  Threat  Allocation 

The  CRC  threat  allocation  processes  may  be  triggered  by  any 
of  the  following  events: 

(1)  CRC  detection  of  a  flight  movement 

(2)  CRC  detection  of  a  flight  death 

(3)  CRC  receipt  of  a  message  from  a  BOC  regarding  a  flight  movement 

(4)  CRC  receipt  of  a  message  from  a  BOC  regarding  a  flight  death 

(5)  CRC  receipt  of  a  message  from  an  interceptor  regarding  the  death 

of  a  red  fl ight 

(6)  CRC  receipt  of  a  message  from  an  interceptor  regarding  the  avail¬ 
ability  of  the  interceptor. 

The  CRC  first  determines  the  direction  of  the  Red  flight.  If  the  Red 
flight  is  returning  home,  it  is  marked  nonavailable  and  no  further  attempts 
are  made  to  assign  either  interceptors  or  SAM  BOC's.  If  the  Red  flight  is 
incoming,  the  CRC  first  attempts  to  assign  the  enemy  flight  to  one  of  its 
airborne  interceptors.  If  no  interceptors  are  currently  airborne,  the  air 
bases  under  the  CRC's  command  are  asked  to  scramble  their  available  air¬ 
craft.  If  no  aircraft  are  available  the  CRC  attempts  to  assign  a  SAM 
battery.  If  an  interception  flight  is  airborne  and  not  already  assigned  to 
a  Red  penetrator  its  ability  (in  terms  of  operational  range)  to  intercept 
the  enemy  flight  is  determined.  If  it  can  intercept  the  enemy  it  is 
assigned  to  do  so  and  the  assignment  process  is  terminated.  If  it  cannot 
intercept  the  enemy  and  no  other  interceptor  flights  are  airborne,  the  CRC 
attempts  to  assign  a  SAM  BOC  to  the  penetrator. 
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In  attempting  to  assign  a  BOC  to  an  incoming  Red  penetrator, 
the  CRC  considers  the  distance  of  the  penetrator  from  the  BOC,  the  altitude 
of  the  penetrator  and  the  saturation  limit  of  the  BOC.  The  CRC  checks  all 
available  BOC's  to  determine  their  distance  from  the  penetrator.  BOC's 
greater  than  1000  km  from  the  penetrator  are  dropped  from  consideration. 
The  CRC  then  checks  the  saturation  levels  of  the  remaining  candidate  BOC's. 
BOC's  with  more  than  30  enemy  flights  already  assigned  are  dropped  from 
further  consideration.  The  altitude  of  the  penetrator  is  then  considered 
to  determine  the  appropriate  type  of  BOC  for  assignment.  Penetrators 
flying  above  3000  meters  are  assigned  to  the  first  available  NIKE-HERCULES 
or  PATRIOT  BOC.  Penetrators  flying  at  or  below  3000  meters  are  assigned  to 
the  first  available  HAWK  or  PATRIOT  BOC.  The  assigned  BOC  then  initiates 
its  own  penetrator  assignment  process  to  determine  which  of  its  subordinate 
batteries  will  be  assigned  to  fire  on  the  penetrators.  If  no  BOC  assign¬ 
ment  can  be  made,  the  incoming  penetrator  is  ignored  until  defensive  assets 
become  available. 

b.  BOC 

Three  types  of  battalion  operations  centers  (BOC)  are 
treated  in  MADEM  --  Hawk,  Nike  Hercules,  and  Patriot.  All  types  are 
treated  in  basically  the  same  way.  MADEM  modeling  for  the  threat  alloca¬ 
tion  processes  of  a  BOC  is  discussed  below  in  terms  of  the  treatment  of  the 
digestion  of  threat  data,  the  tracking  of  the  status  of  subordinate  bat¬ 
teries,  and  the  decision  processes  by  which  particular  subordinates  are 
selected  to  engage  particular  threats. 

1 )  Digestion  of  Threat  Data 

The  threat  digestion  process  for  a  BOC  involves  all 
processing  of  threat  data  relevant  to  the  unit's  allocation  decisions. 
Digestion  of  threat  data  is  represented  in  MADEM  in  terms  of  cyclical 
attention  to  each  member  of  a  particular  set  of  threats  (or  potential 
threats). 

a)  Basic  Representation  of  Digestion  Process 


Associated  with  each  BOC  is  a  data  structure 
called  an  Active  Digested  Information  List  (ADIL).  The  ADIL  includes  one 


element  for  each  threat  currently  in  the  set  of  threats  under  active  con¬ 
sideration.  The  ADIL  is  basically  a  circular  list  of  threats,  and  a 
pointer  into  the  list  indicates,  at  any  time,  the  particular  threat  for 
which  information  is  to  be  digested  next  --  i.e.,  the  next  threat  to  which 
the  BOC  is  to  pay  explicit  attention.  It  is  upon  the  occurrence  of  a 
PONDER(DIGEST)  event  that  data  on  the  next  threat  to  be  considered  is 
actually  digested.  The  model  assumes  that  each  DIGEST  event  requires  a 
certin  minimum  amount  of  time  (MINTIMEDIGEST) .  Thus,  successive  DIGEST 
events  for  a  particular  BOC  must  be  separated  by  at  least  this  interval. 
The  time  required  to  digest  information  on  all  threats  in  the  ADIL  is  then 
equal  to  the  product  of  the  number  of  threats  in  the  ADIL  and  the  minimum 
digest  time.  To  prevent  this  cycle  time  from  getting  arbitrarily  long,  a 
limit  (MAXNUMDIGES f)  is  imposed  on  the  number  of  threats  allowed  in  the 
ADIL  at  any  particular  time.  Once  the  ADIL  is  full,  additional  threats 
which  would  otherwise  be  considered  must  be  ignored  until  one  of  the 
threats  currently  in  the  ADIL  is  dropped  for  some  reason.  When  the  ADIL  is 
not  full,  the  time  between  successive  DIGEST  events  may  be  greater  than  the 
minimum  referenced  above.  In  general,  the  model  attempts  to  keep  the 
digest  cycle  time  at  a  specified  value  (MINCYCLEDIGEST) .  Subject  to  the 
limit  imposed  by  the  minimum  digest  time. 

b)  Inclusion  of  Threats  in  Digestion  Cycle 

Initially,  a  particular  threat  will  be  inserted 
into  the  ADIL  for  one  of  two  reasons.  If  a  BOC  is  under  the  command  of  a 
CRC,  then  only  threats  ass i qned  to  the  BOC  by  the  CRC  will  go  into  the 
ADIL.  In  this  case,  a  threat  inserted  may  not  even  be  initially  detectable 
by  the  BOC.  The  fact  that  the  threat  is  in  the  ADIL  will,  however,  enhance 
the  chances  of  its  detection  when  such  detection  becomes  possible.  For  an 
assigned  threat,  the  probability  that  the  threat  is  detected,  given  it  is 
potentially  detectable,  is  1.0.  If  a  BOC  is  operating  autonomously  (i.e., 
not  under  the  control  of  a  CRC),  then  any  detection  of  a  threat,  or 
potential  threat,  which  is  not  already  in  the  ADIL  will  result  in  immediate 
insertion  of  that  threat,  provided  that  the  ADIL  is  not  full. 
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For  a  80C  operating  under  CRC  control,  it  is 
possible  that  more  threats  may  be  assigned  than  can  be  accommodated  simult¬ 
aneously  in  the  AOIL.  Threats  assigned  when  the  AD  I L  is  full  go  into  a 
Force  Out  Queue  (FOQ)  to  await  the  opening  of  space  in  the  ADIL.  When  such 
an  opening  arises,  the  top  item  on  the  FOQ  is  inserted. 

A  final  way  in  which  threats  are  inserted  into  the 
ADIL  involves  transfer  from  another  list  called  the  Passive  Digested 
Information  List  (PDIL).  A  threat  is  moved  from  the  ADIL  to  the  PDIL  when 
the  BOC  has  allocated  the  desired  level  of  coverage  against  it  by  assigning 
it  to  one  or  more  subordinate  batteries.  The  BOC  pays  no  explicit 
attention  to  threats  on  the  PDIL,  since  responsibility  for  these  threats 
has  been  transferred  to  subordinates.  Should  one  of  these  subordinates 
report  a  significant  change  in  the  threat,  or  should  one  or  more  of  them 
report  inability  to  engage  the  threat,  then  a  resumption  of  consideration 
of  the  threat  by  the  BOC  is  indicated.  In  such  a  case,  an  attempt  is  made 
to  return  the  threat  from  PDIL  to  ADIL.  If  the  ADIL  is  not  full,  there  is 
no  problem.  If  it  is  full,  then  the  considered  threat  may  go  temporarily 
to  the  FOQ,  or  some  low-priority  threat  currently  in  the  ADIL  may  be 
transferred  to  the  FOQ  to  make  room. 

c)  Elimination  of  Threats  from  Digestion  Cycle 

A  particular  threat  may  be  eleminated  from  the 
ADIL  for  any  of  a  number  of  reasons,  some  already  referred  to.  If  an 
assigned  threat  is  inserted  into  the  ADIL  before  it  is  actually  detectable 
by  the  BOC  (or  its  subordinates),  it  will  remain  there  only  120  seconds  if 
not  detected.  When  an  assigned  threat  is  ejected  in  this  fashion,  a 
message  is  sent  to  the  CRC  rejecting  the  assignment. 

A  threat  may  also  be  ejected  from  the  ADIL  as  the 
result  of  a  determination  that  it  is  not  projected  to  be  engageable  by  any 
of  the  BOC's  subordinates.  Such  ejection  by  a  nonautonomous  BOC  is  again 
accompanied  by  an  assignment  rejection  message  to  the  CRC.  A  threat  so 
ejected  by  an  autonomous  BOC  might  well  reenter  the  ADIL  upon  its  next 
movement  (assuming  detection),  but  in  the  meantime  the  ADIL  space  would  be 
available  for  the  entry  of  other  possible  engageable  threats. 


A  threat  once  detected  but  then  lost  to  sight  may 
also  be  ejected  from  the  AOIL  if  not  redetected  sufficiently  soon.  At  each 
DIGEST  event,  the  time  of  the  latest  detected  information  on  the  considered 
threat  is  compared  to  the  time  of  the  last-digested  data.  If  the  two  times 
differ,  then  new  data  is  available  for  digestion;  if  not,  then  either  the 
old  data  will  be  retained  and  the  threat  checked  again  on  the  next  digest 
cycle,  or  the  threat  will  be  ejected  from  the  AOIL.  Ejection  is  indicated 
if  the  last  digested  information  is  older  than  a  specified  threshold 
(LOSTTIME). 

Since  an  autonomous  BOC  will  insert  any  detectable 
flight  into  the  AOIL  if  there  is  room,  both  RED  and  BLUE  flights  may  appear 
in  the  list.  If  digestion  of  data  on  a  particular  threat  leads  to  a  con¬ 
clusion  that  the  considered  flight  is  BLUE,  then  that  flight  will  be  con¬ 
sidered  non-threatening  and  will  be  ejected  from  the  ADIL. 

d)  Nature  of  Basic  Information  Digested 

As  noted  in  a  previous  section,  calculations  to 
determine  the  detectability  of  a  particular  flight  are  carried  out  in 
connection  with  PERCEPT  events  coinciding  in  time  with  FLY  events  for  the 
flight.  The  results  of  each  such  determination  are  then  assumed  to  hold 
until  the  time  of  the  flight’s  next  FLY  event.  Thus,  when  a  particular 
flight  is  considered  in  a  DIGEST  event,  the  outcome  of  that  event  depends 
on  the  results  of  the  most  recent  PERCEPT  events  involving  the  flight  and 
the  BOC  and  its  subordinate  batteries.  When  the  subject  flight  of  the 
DIGEST  is  detectable,  three  types  of  data  may  be  obtained  regarding  the 
f 1 i gh t — i ts  nature  as  friend  or  foe,  its  course,  and  its  size.  In  the  case 
of  a  nonautonomous  BOC,  all  considered  flights  are  assumed  to  be  RED.  The 
BOC  simply  goes  along  with  the  CRC's  prior  assessment  of  the  flight  as  foe. 
A  BOC  operating  autonomously,  however,  must  make  its  own  determination. 
This  determination  is  not  made  on  every  digest  event,  but  only  on  those 
which  involve  the  initial  digestion  of  data  on  a  new  ADIL  entry.  So  long 
as  a  flight  remains  in  the  ADIL,  it  retains  its  original  characterization. 
Each  time  a  particular  threat  reenters  the  ADIL  after  ejection,  its 
identity  as  friend  or  foe  is  determined  anew.  On  each  such  determination. 
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the  model  assumes  a  0.03  probability  that  an  error  will  occur.  Thus,  it  is 
possible  that  certain  BLUE  flights  may  be  assigned  for  engagement,  while 
certain  RED  flights  are  erroneously  rejected  as  targets. 

Digested  data  on  the  course  of  a  considered  flight 
reflects  the  hex  position  of  the  flight  at  the  time  of  its  last  FLY  event, 
along  with  the  flight's  current  heading  and  speed.  Due  to  the  fact  that 
the  flight's  movement  on  the  MADEM  hex  grid  only  approximate  the  actual 
assumed  straight-line  flight  path  legs,  the  actual  projected  course 
resulting  from  a  digest  event  may  vary  somewhat  from  the  actual  assumed 
course.  Any  error  present,  however,  appears  only  as  a  displacement  of  the 
calculated  course  from  that  assumed  in  a  direction  perpendicular  to  the 
flight  heading.  The  maximum  such  displacement  is  half  of  a  9.45  km  hex 
diameter,  which  is  the  same  as  the  uncertainty  for  the  ground  unit  loca¬ 
tions. 

The  size-of-fl ight  data  derived  from  a  DIGEST 
event  reflects  the  actual  current  number  of  aircraft  in  the  flight. 

e)  Processing  of  Basic  Digested  Information 

Since  the  real  purpose  of  the  digestion  process  is 
to  support  the  BOC's  allocation  decision  processes,  the  basic  data  on 
threat  course  and  size  discussed  above  is  transformed  into  direct  inputs 
for  these  processes.  These  inputs  are  of  three  types  --  projected 
engagement  windows,  threat  priorities,  and  desired  coverage  levels. 

1_.  Engagement  Windows 

During  the  course  of  the  simulation,  lists  of 
projected  engagement  windows  are  maintained  for  each  BOC.  Each  BOC  has  an 
individual  list  associated  with  each  flight  under  consideration,  as  well  as 
an  individual  list  associated  with  each  surviving  subordinate  battery. 
Such  lists  may  be  created,  updated,  and  destroyed  as  part  of  the  overall 
digestion  process.  Whenever  new  threat  heading  or  speed  data  is  digested 
for  a  particular  threat,  the  set  of  engagement  windows  implied  by  this 
course  data  is  also  determined,  and  this  data  goes  into  a  new  list  of 
windows  for  the  considered  threat.  The  data  is  also  used  to  update  window 
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lists  for  the  individual  batteries.  Any  engagement  windows  based  on  pre¬ 
vious  (now  superseded)  course  data  for  the  considered  threat  are  elimi¬ 
nated. 

Individual  engagement  windows  are  generated 
by  calculating  times  of  entry  into  and  exit  from  the  engagement  areas  of 
individual  subordinates.  For  Hawk  and  Nike  Hercules  systems,  engagement 
areas  are  assumed  to  be  circular.  The  area  for  a  particular  battery  is 
centered  at  the  battery  location  and  has  a  specified  radius  ( MI SS I LE RANGE ) . 
For  Patriot  batteries  (firing  sections),  the  engagement  area  has  the  shape 
of  a  circular  wedge,  with  the  tip  of  the  wedge  at  the  battery  location. 
The  total  shape  of  the  wedge  is  determined  by  a  specified  radius  (MISSILE- 
RANGE),  a  specified  center  line  (primary  target  line)  orientation,  and  the 
angular  width  (  °)  of  the  wedge.  In  the  actual  windows  opening  and 
closing  calculations,  allowance  is  made  for  the  lead  time  in  firing 
required  to  achieve  intercept  at  the  points  of  entry  into  and  exit  from  the 
engagement  area.  Thus,  the  window's  limits  generated  are  limits  on  f i ri nq 
time ,  rather  than  on  intercept  time.  In  making  the  firing  time  calcula¬ 
tions,  the  nominal  flyout  speed  of  the  missile  (MISSILERANGE/TIMEFLIGHT)  is 
employed.  A  projected  window  of  less  than  a  specified  time  length 
(ENGAGEWINDOW)  is  treated  as  no  window  at  all. 

The  calculation  of  projected  engagement 
windows  involves  no  consideration  of  the  altitude  of  the  considered  flight. 
The  CRC  considers  threat  altitude  in  assigning  targets,  and  the  battery 
units  consider  altitude  after  achieving  track  on  threats,  but  the  BOC  does 
not  consider  threat  altitude  at  all. 

2_^  Threat  Priority 

A  BOC  assigns  priorities  to  considered 
threats  on  the  basis  of  their  headings  and  the  times  of  the  latest  pro¬ 
jected  opportunities  to  engage  them.  The  prime  determinant  is  heading. 
Three  priority  categories  are  defined  as  follows: 

Category  1  -  threats  with  headings  45°  or  less  off 

of  due  west 
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Category  2 


threats  with  headings  between  45°  and 
90°  oft  due  west 
Category  3  -  all  other  (eastbound)  threats 

Within  each  category,  threats  are  ranked  in  order  of  the  times  of  last 
engagement  opportunity.  Those  threats  for  which  the  opportunity  to  engage 
will  pass  most  quickly  are  given  highest  priority. 

3.  Desired  Coverage 

On  the  basis  of  the  number  of  aircraft 
included  in  a  particular  flight,  a  BOC  determines  the  level  of  coverage 
appropriate.  Level  of  coverage  is  measured  in  terms  of  the  number  of 
simultaneous  independent  engagements  to  be  carried  on  against  the  member 
aircraft  of  the  flight.  Included  in  the  MADEM  data  base  for  each  BOC  type 
are  desired  coverage  levels  for  flights  of  one  (C0V0N0NE),  of  "few" 
(C0V0NFEW),  and  of  "many"  (C0V0NMANY)  aircraft.  Also  included  is  the 
specified  dividing  line  (FEW)  between  "few"  and  "many". 

2)  Tracking  of  Subordinate  Status 

In  situations  in  which  a  BOC  has  the  option  of 
assigning  a  given  threat  to  any  of  a  number  of  subordinate  batteries,  the 
decision  as  to  which  battery  in  particular  should  receive  the  assignment  is 
based  on  the  current  levels  of  readiness  of  the  individual  batteries  and  on 
the  load  already  imposed  on  each.  A  BOC 1  s  perception  of  the  status  of  a 
particular  battery  is  based  on  an  initial  knowledge  of  its  status,  updated 
during  the  course  of  the  simulation  on  the  basis  of  assignments  made  to  and 
messages  received  from  the  battery. 

a)  Initial  Status  Data 

At  the  outset  of  the  simul'  m,  •«  BOC  knows  the 
(constant)  location  of  each  battery,  the  total  number  of  rounds  of 
ammunition,  and  the  maximum  number  of  independent  concurrent  engagements 
which  the  battery  can  carry  on.  While  the  total  number  of  rounds  is  known 
for  each  battery,  the  breakdown  of  this  ammunition  by  type  (conventi onal , 


low-yield  nuclear,  high-yield  nuclear)  is  not  known  for  those  system  types 
where  a  mix  of  types  is  allowed. 

b)  Updating  of  Status  Data 

During  the  course  of  the  simulation  a  battery  may 
send  a  variety  of  messages  to  its  superior  BOC.  Some  types  carry  specific 
status  information  on  the  battery  itself,  while  others  carry  information  on 
the  status  of  a  current  assignment  of  the  battery. 

At  the  time  of  each  missile  firing,  a  battery 
sends  a  message  which  indicates  the  number  of  rounds  expended,  and  also 
indicates  any  reduction  in  the  number  of  independent  concurrent  engagements 
the  battery  can  support.  For  example,  if  a  firing  exhausted  the  ammunition 
for  one  of  the  two  fire  units  of  a  Hawk  battery,  the  firing  report  would 
indicate  a  reduction  of  one  in  the  engagement  capacity  of  the  battery.  A 
message  is  also  sent  to  the  BOC  when  new  ammunition  becomes  available  to 
the  battery  in  connection  with  a  RESUPPLY/RELOAD  event.  This  message  is 
effectively  the  inverse  of  the  firing  report,  in  that  it  indicates  rounds 
added  and  engagement  capacity  added,  if  any. 

With  regard  to  a  particular  assigned  target,  a 
battery  may  send  messages  indicating  the  effective  end  of  the  assignment. 
Such  messages  may  indicate  either  a  successful  termination,  due  to 
destruction  of  the  target,  or  an  unsuccessful  one,  due  to  closing  of  the 
engagement  window.  In  either  case,  such  messages  report  a  lightening  of 
the  current  assignment  load  on  the  battery.  Batteries  also  report  the 
destruction  of  individual  aircraft  within  flights,  so  that  BOC's  may 
reassess  the  coverage  level  appropriate  for  the  diminished  flight. 

A  battery  may  also  send  a  message  to  its  commander 
the  effect  of  which  is  to  cause  the  BOC  to  check  on  a  particular  target  to 
determine  if  its  assignment  to  the  reporting  battery  is  still  justified. 
Such  a  message  is  sent  when  an  assigned  target  is  not  sighted  as  expected, 
or  when  it  is  initially  detected  but  subsequently  lost  to  sight.  When  an 
assigned  target  is  observed  to  deviate  significantly  from  the  course 
indicated  by  the  BOC  in  the  original  target  assignment  order,  a  similar 
message  is  sent.  In  this  case,  however,  the  message  is  intended  more  to 


make  the  BOC  aware  of  the  possibility  of  new  engagement  opportunities  for 
other  batteries  than  to  indicate  any  important  change  in  the  status  of  the 
reporting  battery  itself.  In  an  instance  in  which  the  course  change  was  so 
dramatic  as  to  preclude  the  battery  from  engaging  the  target,  the  battery 
would  simply  report  a  closing  of  the  engagement  window. 

3)  Assignment  of  threats  to  batteries 

The  basic  goal  of  each  BOC  player  in  the  MADEM  simu¬ 
lation  is  to  see  that  an  appropriate  level  of  coverage  is  maintained  on 
each  considered  threat  at  all  times.  A  BOC  achieves  this  coverage  by 
assigning  the  threat  to  one  or  more  subordinate  batteries.  Decisions  as  to 
which  threats  will  be  assigned  to  which  subordinates,  and  when,  are  made  on 
the  basis  of  the  digested  threat  data  and  subordinate  status  information 
discussed  above.  There  are  three  basic  situations  in  which  a  BOC  in  MADEM 
may  make  a  threat  assignment.  One  of  these  involves  the  consideration  of  a 
particular  threat  which  is  not  sufficiently  covered.  Another  involves  the 
consideration  of  a  particular  subordinate  with  currently  idle  engagement 
capacity.  The  third  involves  the  opening  of  an  engagement  window  involving 
a  particular  threat  and  battery  combination.  The  nature  of  the  assignment 
decision  in  each  situation  will  be  discussed  in  turn,  and  instances  in 
which  a  battery  may  be  ordered  to  reduce  its  coverage  of  a  threat  will  then 
be  di scussed. 

a)  Selection  of  Battery(s)  to  Cover  a  Threat 

There  are  a  number  of  circumstances  under  which  a 
BOC  in  MADEM  will  seek  a  particular  battery,  or  batteries,  to  which  a 
particular  considered  threat  can  be  assigned.  Some  of  these  circumstances 
arise  in  the  threat  data  digestion  process,  while  others  arise  from  the 
processing  of  reports  from  subordinates. 

When  a  particular  threat  is  initially  considered 
in  the  digestion  process,  and  engagement  windows  are  projected  as  a  result, 
the  BOC  will  make  its  initial  attempt  to  cover  (assign)  the  threat.  Also, 
when  digestion  of  new  information  on  a  previously  considered  threat 
indicates  a  course  change  resulting  in  new  engagement  opportunities,  an 
attempt  to  assign  new  coverage  may  occur. 
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The  above  ci rcumstances  under  which  there  may  be 
an  attempt  to  assign  a  threat  relate  basically  to  the  realization  of  new 
engagement  opportunities.  Attempts  to  assign  may  also  arise  out  of  the 
realization  of  the  ends  of  previously  projected  opportunities.  In  such  a 
case,  the  spur  to  the  assignment  attempt  will  be  a  report  from  some  sub¬ 
ordinate  to  which  the  considered  threat  was  previously  assigned.  A  sub¬ 
ordinate  might,  for  example,  report  the  closing  of  its  engagement  window 
against  an  assigned  threat.  In  such  a  case,  another  subordinate  must  be 
sought  to  replace  the  lost  coverage  on  the  particular  threat  considered. 
Alternatively,  a  battery  might  report  its  total  disablement  by  air-to- 
ground  attack.  In  tnis  case,  alternative  coverage  must  be  sought  for  all 
of  the  threats  currently  assigned  to  the  disabled  subordinate.  A  battery 
might  also  report  a  decrease  in  engagement  capacity  due  to  ammunition 
expenditure.  Such  a  decrease  would  imply  a  decrease  in  the  maximum 
allowable  load  for  the  battery.  In  a  situation  in  which  the  battery's 
current  load  exceeds  the  new  allowable  maximum,  the  load  is  reduced  by 
cancel  1 i ng  .one  or  more  of  the  current  assignments.  There  is  then  a  need  to 
seek  other  batteries  to  which  assignments  can  be  made  to  compensate  for  the 
lost  coverage. 

A  particular  battery,  or  set  of  batteries,  is 
selected  to  engage  a  considered  threat  on  the  basis  of  the  following: 

(1)  timing  of  projected  engagement  windows 

(2)  current  engagement  capacities  of  batteries 

(3)  current  loads  on  batteries 

(4)  current  ammunition  stocks  of  batteries. 

Only  batteries  for  which  a  projected  engagement  window  against  the  threat 
is  currently  open,  or  will  open  within  two  minutes,  are  considered  as  can¬ 
didates  for  assignment  to  the  considered  threat.  Also,  only  batteries 
which  do  not  already  have  a  full  assignment  load  are  considered.  These 
batteries,  if  any,  which  satisfy  the  above  criteria  are  divided  among  the 
following  three  perference  categores: 

(1)  batteries  for  which  there  is  adequate  response  time,  and  for 
which  the  current  engagement  capacity  exceeds  the  current 
engagement  load 
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(2)  batteries  for  which  there  is  adequate  response  time,  but  for 
which  current  engagement  capacity  does  not  exceed  the  current 
engagement  load 

(3)  batteries  for  which  there  is  minimal  time  to  respond,  and  for 
which  the  current  engagement  capacity  exceeds  the  current 
engagement  load 

Response  time  adequacy  is  determined  by  the  closing  time  of  the  relevant 
engagement  window.  If  the  time  between  the  assignment  decision  and  the 
projected  closing  of  the  window  does  not  exceed  a  specified  threshold 
( LOWRESPTIME) ,  the  likelihood  that  the  battery  involved  could  successfully 
respond  to  an  assignment  order  is  assumed  to  be  low.  Thus,  preference  is 
given  to  assignments  where  the  projected  time  to  respond  is  adequate.  A 
secondary  preference  is  given  to  batteries  which  can  immediately  undertake 
engagement  could  be  supported  concurrently  with  those  against  any  already 
assigned  targets.  It  may  be  noted  that  the  above  listed  preference 
categories  do  not  cover  all  assignment  candidates  as  defined  above.  Those 
for  which  there  is  minimal  response  time  and  for  which  the  battery  could 
not  support  another  independent  engagement  immediately  are  eliminated  from 
consideration. 

Within  each  of  the  three  general  preference  categories 
defined  above,  individual  batteries  are  ranked  in  order  of  ammunition 
available  minus  engagement  load.  Batteries  are  selected  for  assignment  in 
accordance  with  the  indicated  preference  order  until  the  desired  level  of 
coverage  has  been  achieved  against  the  considered  threat,  or  until  all 
currently  possible  assignments  of  the  threat  have  been  made.  A  particular 
battery  selected  to  engage  the  threat  may  be  assigned  to  provide  more  than 
one  unit  of  coverage  (independent  engagement)  on  the  threat.  Such  coverage 
will  be  ordered  if  called  for  by  the  size  of  the  threat  and  made  possible 
by  the  engagement  capacity  of  the  battery. 

b)  Selection  of  Threat(s)  to  be  Covered  bv  a  Battery 

A  perceived  change  in  the  status  of  a  particular  sub¬ 
ordinate  may  give  a  BOC  reason  to  seek  some  new  assignment(s)  for  that 
subordinate.  For  example,  a  report  from  a  battery  indicating  the  activa¬ 
tion  of  new  engagement  capacity  due  to  ammunition  resupply  will  occasion 
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such  a  search.  Similarly,  a  reduction  of  the  load  on  a  battery  may  be 
reason  to  seek  new  assignments  to  make  maximal  use  of  the  battery.  Such  a 
load  reduction  may  result  from  the  end  of  a  previous  engagement,  or  from  a 
reduction  in  the  assigned  coverage  level  against  some  threat. 

When  assignments  are  to  be  sought  for  a  particular 
threat,  only  those  threats  which  are  in  the  BOC's  active  digested  infor¬ 
mation  list  and  which  do  not  have  the  desired  level  of  coverage  assigned 
are  considered.  Such  threats  for  which  the  considered  battery  has  open,  or 
soon  to  open,  projected  engagement  windows  are  split  between  two  preference 
categories: 

(1)  threats  for  which  the  battery  has  adequate  projected  response 

time 

(2)  threats  for  which  the  battery  has  minimal  projected  response 

time. 

Again,  response  time  adequacy  is  based  on  the  time  to  the  projected  window 
closing  for  the  threat;  if  this  time  exceeds  a  threshold  (LOWRESPTIME) , 

there  is  assumed  to  be  adequate  time  for  the  battery  to  respond  to  an 
engagement  order.  Within  each  category,  individual  threats  are  ranked  in 
order  of  their  assigned  priorities.  Tracks  are  selected  for  assignment  to 
the  battery,  in  accordance  with  the  discussed  preference  order,  until  the 
battery  is  fully  loaded,  or  until  all  allowed  assignments  have  Deen  made. 

If  a  threat  is  selected  for  which  the  current  coverage  shortfall  is  greater 

than  one,  then  the  battery  may  be  assigned  more  than  one  unit  of  coverage 

on  the  threat,  assuming  that  it  is  capable  of  simultaneous,  independent  ' 

engagement  of  members  of  the  threat  flight. 

c )  Consideration  of  Projected  Window  Openings  i 

As  indicated  previously,  a  BOC  in  MADEM  will  not  [ 

assign  a  threat  to  ittery  more  than  two  minutes  in  advance  of  the  pro¬ 
jected  opening  of  the  relevant  engagement  window.  Thus,  some  projected  I 

engagement  windows  cannot  be  used  as  bases  for  assignment  decisions  until 
some  time  has  passed  after  their  generation  by  the  process  of  threat  data 
digestion.  When  a  window  is  projected  which  cannot  be  used  immediately,  an 
event  is  scheduled  to  occur  in  the  simulation  at  the  time  at  which  the  BOC 
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could  first  make  an  assignment  decision  on  the  basis  of  the  projection. 
The  occurrence  of  this  event  (called  an  OPPORTUNITY  KNOCKS  event)  causes 
the  BOC  to  consider  assigning  the  threat  involved  to  the  battery  involved. 
Such  an  assignment  will  occur  if  the  threat  is  not  already  fully  covered, 
and  the  battery  is  not  already  fully  loaded. 

d)  Reduction  in  Battery  Assignments 

A  BOC  may  decide  to  reduce  the  assignment  load  of 
a  battery  for  either  of  two  basic  reasons.  The  first  of  these  reasons  is  a 
decrease  in  perceived  size  of  an  assigned  threat.  A  BOC  may  become  aware 
of  attrition  of  a  flight  either  through  its  own  digestion  process  or 
through  reports  from  its  subordinates.  When  a  change  is  noted  which 
implies  a  change  in  the  level  of  coverage  appropriate  for  the  threat  (i.e., 
a  change  from  "many"  to  "few"  or  a  change  from  "few"  to  one),  the  BOC  can 
reduce  the  coverage  by  cancelling  an  assignment,  or  by  reducing  the 

coverage  level  associated  with  a  particular  assignment.  When  a  choice  is 
to  be  made  regarding  which  battery  should  have  its  load  reduced  in  con¬ 
nection  with  a  coverage  reduction,  the  candidate  with  the  least  ammunition 
surplus  (ammunition  stock  minus  load)  is  selected. 

The  second  reason  for  reducing  the  assignment  load 
on  a  battery  is  a  decrease  in  the  engagement  capacity  of  the  battery. 

Since  the  maximum  allowable  load  for  a  battery  is  calculated  as  a  multiple 

(MAXASSIGN)  of  the  current  engagement  capacity,  a  decrease  in  this  capacity 
may  leave  the  battery  overloaded.  In  such  an  instance,  the  BOC  relieves 
the  battery  of  some  of  its  assignments.  Assignments  are  cancelled,  as 

necessary,  in  reverse  order  of  the  priorities  of  the  threats  involved, 
c.  Battery 

Three  types  of  SAM  batteries  are  treated  in  MADEM  --  Hawk, 
Nike  Hercules,  and  Patriot.  Many  aspects  of  the  modeling  of  threat  allo¬ 
cation  processes  in  MAOEM  are  common  for  all  three  battery  types.  The 

major  differences  among  modeling  for  the  three  relates  to  the  treatment  of 

engagement  capacity  for  a  battery.  A  Hawk  battery  is  treated  as  two 

distinct  fire  units.  Each  fire  unit  has  its  own  ammunition  supply,  and  the 

two  fire  units  can  engage  separate  targets  independently.  When  a  fire  unit 
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runs  out  of  ammunition,  the  engagement  capacity  of  the  battery  is  decreased 
by  one.  A  Nike  Hercules  battery  is  treated  as  a  single  fire  unit;  thus, 
the  engagement  capacity  of  such  a  unit  is  always  one,  so  long  as  ammunition 
remains.  A  Patriot  battery  player,  which  actually  more  nearly  represents  a 
Patriot  f i ri nq  secti on ,  is  treated  as  a  single  unit  with  a  capacity  for 
multiple  simultaneous  independent  engagements,  all  of  which  draw  upon  the 
common  ammunition  supply  associated  with  the  unit.  The  maximum  number  of 
simultaneous  engagements  allowed  to  such  a  unit  is  subject  to  the  con¬ 
straint  that  there  must  be  at  least  one  missile  committed  to  each  engage¬ 
ment  in  progress  at  any  given  time. 

The  discussion  of  the  threat  allocation  process  for 
batteries  which  follows  will  be  similar  in  form  to  the  previous  discussion 
of  such  processes  for  BOC's.  Digestion  of  threat  data  will  be  treated 
first.  The  tracking  of  fire  unit  (engagement  capacity)  status  will  then  be 
touched  upon.  Finally,  the  decision  processes  by  which  particular  threats 
are  selected  for  engagement  by  particular  fire  units  will  be  discussed. 

The  threat  digestion  process  for  a  battery  in  MADEM  involves 
all  processing  of  threat  data  relevant  to  the  unit's  engagement  decisions. 
The  basic  nature  of  the  digestion  process  is  identical  to  that  discussed 
earlier  in  connection  with  BOC's. 

The  battery  maintains  an  Active  Digested  Information  List 
(ADIL)  eguivalent  to  that  maintained  by  a  BOC.  For  a  nonautonomous 
battery,  only  threats  assigned  by  the  commanding  BOC  are  entered  in  the 
ADIL  for  processing.  For  an  autonomous  battery,  all  detectable  threats  go 
into  the  ADIL,  so  long  as  the  ADIL  is  not  filled  to  capacity.  Each  battery 
also  has  a  Force  Out  Queue  (FOQ)  which  serves  the  same  function  as  for  a 
BOC.  A  battery  does  not  have  a  Passive  Digested  Information  List  (PDIL), 
since  a  battery  has  no  subordinates  to  which  it  can  pass  off  threats.  Each 
battery  does,  however  have  a  corresponding  structure  called  the  tracked 
list.  Threats  are  moved  to  this  list  from  the  ADIL  when  tracking  of  the 
threat  is  initiated  as  part  of  an  actual  engagement.  Threats  on  the 
tracked  list  are  effectively  under  continuous  scrutiny.  New  information  is 
digested  on  such  a  threat  immediately  each  time  it  moves;  there  is  no  wait 
for  the  threat  to  be  reached  in  the  normal  cycle  through  the  ADIL. 


A  significant  difference  between  ADIL  entries  for  BOC's  and 
batteries  is  that  assigned  threats  have  associated  course  data  when 
initially  added  to  the  ADIL  by  batteries.  This  data  is  passed  to  the 
battery  by  the  BOC.  No  such  data  is  passed  from  CRC  to  BOC.  After  a  bat¬ 
tery  initially  digests  data  on  an  assigned  threat,  it  can  detect  any  course 
change  which  has  taken  place  since  the  BOC's  last  digestion  of  data  on  the 
threat  prior  to  its  decision  to  assign.  This  allows  the  battery  to  report 
such  changes  to  the  BOC,  so  that  the  BOC  might  reassess  its  previous  deci¬ 
sions. 

The  particular  threat  data  digested  by  batteries  --  flight 
"side",  course,  and  size  --  is  identical  to  that  for  BOC's.  Like  BOC's, 
batteries  assume  assigned  threats  to  be  RED.  Confusion  of  the  loyal ity  of 
unassigned  threats  is  handled  similarly. 

For  an  autonomous  battery,  the  basic  outputs  of  the  diges¬ 
tion  process  are  the  same  as  for  BOC's  --  engagement  windows,  threat 
priorities,  and  desired  coverage  levels.  For  a  battery  under  command  of  a 
BOC,  however,  the  desired  coverage  level  for  each  threat  is  specified  by 
the  assignment  order.  This  level  can  be  changed  only  by  further  orders 
from  the  BOC. 

A  battery  calculates  engagement  windows  for  itself  in  the 
same  manner  as  a  BOC  does  for  each  of  its  subordinates.  Should  a  battery's 
window  determination  indicate  that  no  window  for  an  assigned  threat  -- 
perhaps  due  to  course  change,  or  to  insufficient  response  time  --  the 
battery  will  report  a  window  closing  to  its  BOC  and  give  up  on  the  assign¬ 
ment. 

A  non-autonomous  battery  assigns  priorities  to  threats  in 
the  same  manner  as  does  a  BOC,  cn  the  basis  of  heading  and  last  opportunity 
(of  the  considered  battery  only)  to  engage.  Priority  assignment  by 
autonomous  batteries  is  basically  similar,  but  differs  in  the  precise 
manner  in  which  threat  heading  is  treated.  Instead  of  assigning  highest 
priority  to  threats  whose  headings  are  within  45°  of  due  west,  an  auto¬ 
nomous  battery  gives  top  priority  to  threats  with  headings  within  45°  of  a 
direction  specified  for  the  individual  unit.  Each  battery  has  a  Primary 


Target  Line  (PTL)  defined  in  terms  of  a  heading  from  the  units  position. 
Flights  approaching  from  the  direction  of  the  primary  target  line  are  given 
top  priority.  Second  and  third  priority  categories  are  defined  as  before, 
but  with  the  role  of  due-west  being  taken  by  the  heading  PTL+1800. 

For  autonomous  batteries,  the  determination  of  the  coverage 
level  appropriate  for  a  threat  is  carried  out  just  as  for  a  BOC.  The 
coverage  levels  appropriate  for  one,  few,  and  many  may  be  different,  how¬ 
ever,  from  those  accessed  by  the  BOC,  since  the  data  used  by  the  battery  is 
accessed  from  a  battery  type  data  base  instead  of  from  the  BOC  type  data 
base.  The  battery  type  data  base  should  not  indicate,  for  any  size  flight, 
a  desired  coverage  greater  than  the  maximum  engagement  capacity  of  the 
battery. 

The  basic  goal  of  each  battery  player  in  the  MADEM  simula¬ 
tion  is  to  see  that  an  appropriate  level  of  coverage  is  maintained  on  each 
considered  threat  at  all  times.  A  battery  seeks  to  achieve  this  goal  by 
allocating  appropriate  firepower  against  each  threat.  In  the  case  of  a 
Nike  Hercules  battery,  there  is  not  question  of  which  firepower  should  be 
allocated,  since  there  is  only  one  fire  unit  available.  The  case  of  a 
Patriot  battery  is  basically  similar,  in  that  all  firepower  is  assumed  to 
be  allocated  from  a  single  common  pool.  In  the  case  of  a  Hawk  battery, 
however,  two  fire  units  are  represented  as  distinct  entities.  A  separate 
ammunition  stock  is  tracked  for  each,  and  there  is,  thus,  a  basis  for 
selecting  a  particular  fire  unit  for  a  given  engagement. 

Decisions  resulting  in  the  allocation  of  firepower  to  par¬ 
ticular  threats  are  made  in  two  basic  situations.  One  of  these  involves 
the  consideration  of  a  particular  threat  which  is  not  adequately  covered. 
The  other  involves  the  consideration  of  newly  idle  firepower. 

A  battery  may  decide  to  allocate  firepower  against  a  threat 
at  the  time  at  which  the  threat  is  initially  considered  in  the  digestion 
process.  This  will  happen  if  an  engagement  window  of  significant  length  is 
projected  and  idle  firepower  is  available.  Also,  firepower  may  be 
allocated  against  a  threat  as  the  result  of  new  window  projections 
generated  during  subsequent  treatments  of  the  threat  in  the  digestion 


process.  Firepower  is  to  be  allocated  in  order  of  available  ammunition,  in 
order  to  keep  both  fire  units  operational  for  as  long  as  possible. 

Whenever  new  firepower  becomes  available,  a  battery  will 
seek  a  threat  (or  threats)  to  occupy  that  firepower.  New  firepower  may 
become  available  as  the  result  of  an  engagement  ending,  or  as  the  result  of 
a  RESUPPLY/RELOAD  event  for  the  battery.  Threats  for  engagement  are  chosen 
from  among  those  with  currently  projected  engagement  windows,  in  accordance 
with  threat  priority. 

Just  as  BOC's  may  decide  that  subordinate  batteries  should 
reduce  coverage  levels  on  certain  threats,  so  also  may  autonomous  batteries 
decide  to  reduce  coverage.  Thus,  for  example,  an  autonomous  Hawk  battery 
might  start  out  engaging  a  flight  of  "few"  aircraft  with  both  fire  units, 
but  continue  the  engagement  with  just  one  fire  unit  when  the  target  had 
been  attrited  to  just  one  aircraft.  When  a  Hawk  battery  does  engage  a 
single  flight  with  both  fire  units,  it  will  cease  fire  first  with  the  fire 
unit  with  less  ammunition. 

d.  Interceptors 

Interceptors  are  normally  vectored  to  intercept  incoming 
penetrator  flights  by  their  commanding  CRC.  However,  interceptors  will 
also  engage  penetrators  which  pass  within  one  hex  (9.45  km)  of  their  flight 
paths.  After  each  engagement,  surviving  interceptor  flights  request  orders 
from  their  CRC.  If  the  CRC  is  still  alive  and  able  to  communicate,  inter¬ 
ceptors  with  sufficient  fuel  remaining  will  be  assigned  to  new  target 
penetrators.  Interceptors  with  insufficient  fuel  will  return  to  their 
respective  airbases. 

When  an  interceptor's  commanding  CRC  has  been  destroyed  or 
cannot  communicate,  the  interceptor  returns  to  its  airbase  and  assumes  a 
CAP  orbit  until  it  must  land  for  refueling.  Any  penetrators  encountered  on 
the  return  flight  will  be  engaged  by  the  interceptor  if  its  fuel  level 
allows.  If  it  has  insufficient  fuel  it  will  attempt  to  disengage  and 
retreat  to  its  air  base. 
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e.  Air  Bases 

Under  normal  conditions  blue  airbases  launch  interceptors 
only  in  response  to  orders  from  their  commanding  CRC.  However,  if  their 
CRC  is  destroyed  air  bases  will  launch  interceptors  to  fly  defensive  CAP 
orbits.  These  interceptors  will  defend  the  air  bases  by  engaging  any 
penetrators  which  close  to  within  on  hex  (9.45  km)  of  the  base. 

5.  Engagements 

a.  Air-Air  Engagement 

Air-air  engagements  in  MADEM  are  treated  in  terms  of  salvo 
exchanges  of  user  defined  ordnance  packages  between  flights  of  aircraft 
located  in  the  same  or  adjacent  hexes.  Interceptors,  fighters  or  fighter- 
bombers  with  a  designated  air-air  capability  all  can  engage  airborne  tar¬ 
gets;  up  to  10  separate  air-air  ordnance  types  can  be  allocated  to  each 
generic  air-air  flight. 

Target  acguisition  for  air-air  combat  can  occur  in  three 
ways.  First,  a  hostile  flight  may  move  into  the  same  hex  or  a  hex  adjacent 
to  the  one  currently  occupied  by  a  flight.  Second,  a  flight  may  move  into 
a  hex  and  perceive  a  hostile  flight  in  the  same  or  an  adjacent  hex. 
(Identification/  Friend  or  Foe  is  assumed  to  be  perfect  for  airborne 
systems,  i.e.,  visual  identification  before  engagement  is  assumed.) 
Finally  a  flight  may  perceive  that  it  is  under  attack  by  a  hostile  air¬ 
craft.  After  acguiring  a  hostile  flight,  an  evaluation  is  made  of  the 
capability  to  carry  out  a  successful  attack. 

Assuming  that  a  flight  is  not  actively  engaging  a  target,  it 
will  engage  any  hostile  flights  encountered  as  long  as  air-air  ordnance  of 
any  type  and  fuel  remain  available.  An  11  second  "reaction  time"  delay 
occurs  between  detection  of  a  hostile  flight  and  launching  of  ordnance. 
During  this  period,  the  attacking  flight  goes  to  aircombat  speed;  if  the 
flight  is  an  interceptor  flight  and  if  the  detected  hostile  flight  is  not 
the  target  originally  assigned  by  the  CRC,  a  message  is  sent  to  the  CRC 
indicating  that  a  target  of  opportunity  is  being  attacked.  If  the  flight 
initiating  the  attack  is  a  fighter-bomber  flight,  all  air-ground  ordnance 
is  jettisoned  before  launching  air-air  ordnance. 
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The  actual  engagement  process  model  for  air-air  combat 
consists  of  choosing  an  ordnance  package  from  the  remaining  air-air 
ordnance  remaining  for  the  attacking  flight;  launching  a  salvo;  and  damage 
assessment.  Ordnance  packages  are  user  defined  weapons  groupings  to  be 
launched  simultaneously  by  each  aircraft,  e.g.,  1  AIM-7  missile,  2  AIM-9 
missiles,  half  second  air-air  gun  bursts,  etc.  Ordnance  packages  are 
developed  independently  for  each  aircraft  type,  and  thus  are  intended  to 
reflect  the  ordnance  compatibility  of  alternate  aircraft,  as  well  as 
expected  tactics  and  firing  doctrine.  Ordnance  packages  are  chosen  based 
on  a  fixed  priority  developed  for  each  aircraft  type;  lower  priority 
packages  are  not  employed  until  all  higher  priority  packages  have  been 
expended. 

After  the  applicable  ordnance  package  has  been  chosen,  each 
aircraft  in  the  attacking  flight  fires  its  ordnance  package;  total  salvo 
size  is  thus  dependent  on  the  attacking  flight  size,  as  shown  in  the 
figure.  Available  ordnance  for  the  flight  is  updated  to  reflect  the 
expenditure  of  salvos  independently  for  each  flight. 

All  ordnance  in  a  salvo  is  assumed  to  be  launched  simul¬ 
taneously;  attrition  is  based  on  a  sequential,  independent  MONTE  CARLO 
process  employing  user  developed  probability  of  kill  (P^)  values  for  each 
ordnance  package  against  a  single  aircraft.  Currently,  values  do  not 
reflect  alternate  vulnerabilities  for  different  aircraft  types,  dynamic 
degradation  of  weapon  effectiveness  of  ECM,  or  changes  in  Pk  as  a  function 
of  differences  in  target  vs.  firing  flight  range  and  altitude.  One  MONTE 
CARLO  replication  is  made  for  each  ordnance  package  launched  in  a  salvo, 
due  to  the  large  number  of  total  engagements  expected  for  typical  model 
cases. 

The  primary  result  of  the  assumptions  discussed  above  is 
that  attacking  aircraft  do  not  engage  target  flights  independently  but 
sequentially,  with  the  exception  that  an  entire  salvo  is  always  expended, 
even  if  no  targets  remain  for  the  final  ordnance  packages.  For  example,  if 
a  flight  of  four  interceptors  engages  a  flight  composed  of  a  single 
fighter,  four  ordnance  packages  are  always  launched,  even  for  cases  where 
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the  nominal  first,  second,  or  third  packages  kill  the  aircraft.  Damage 
assessment  and  kill  removal  is  immediate  in  the  model;  no  partial  damage  is 
considered.  In  the  event  that  an  interceptor  entirely  destroys  its  target 
flight,  it  sends  a  message  to  its  commanding  CRC  (if  the  CRC  is  alive) 
indicating  target  destruction  and  availability  for  assignment  to  a  new 

target.  Penetrating  flights  which  destroy  their  targets  continue  to  their 
assigned  targets  from  their  present  position  unless  they  have  expended  all 
of  their  air-air  munitions.  Any  flight  which  has  expended  all  of  its 

air-air  munitions  or  has  exhausted  its  combat  fuel  returns  to  its  home 

air  base. 

After  a  salvo  has  been  launched  and  the  damage  assessed, 
available  ordnance  for  the  attacking  flight  is  updated.  Three  seconds 
after  ordnance  is  launched,  the  flight  under  attack  perceives  that  it  has 
been  attacked;  survivors  of  the  salvo  have  an  opportunity  to  react. 
Flights  with  an  air-air  capability,  remaining  air-air  ordnance  and 

remaining  fuel  for  air  combat  will  respond  to  an  attack  by  scheduling  a 
counter  attack,  after  an  11  second  delay.  Fighter-bombers  without  air-air 
capability,  bombers,  and  any  aircraft  flight  returning  to  its  home  airbase 
because  of  fuel  or  air-air  ammunition  depletion  do  not  react  to  air 
attacks. 

Once  an  air-air  engagement  is  initiated,  it  continues  until 
one  of  the  following  events  occurs: 

(1)  The  targeted  flight  evades  the  attacker; 

(2)  The  targeted  flight  is  destroyed; 

(3)  The  attacking  flight  is  destroyed; 

(4)  The  attacking  flight  depletes  its  fuel  or  air-air  ordnance  and 
breaks  off. 

The  major  driver  is  a  continuing  engagement  in  movement  of 
the  flights.  Scheduling  of  movement  is  based  on  flight  speed  and  is 
independent  of  scheduling  for  aircombat  events;  thus,  for  example,  a  faster 
aircraft  flight  can  rapidly  evade  a  slower  attacking  flight.  However, 
scheduling  of  aircombat  events  is  coupled  to  movement;  an  attacking  flight 
can  fire  only  one  salvo  at  a  target  flight  unless  it  moves  or  fires  a 
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retaliatory  salvo.  This  feature  is  intended  to  prevent  unconstrained 
firing  of  multiple  salvos  at  low  speed  flights.  In  the  event  that  an 
interceptor  flight  destroys  its  target  or  expends  all  of  its  fuel /air-air 
ordnance,  it  sends  a  status  message  to  its  commanding  CRC.  In  the  event 
the  interceptor  flight  is  destroyed,  the  CRC  is  immediately  aware  of  the 
loss. 

Offensive  fighters  and  fighter-bomber  flights  engage  only 
c.ir-air  targets  of  opportunity  ( i .  e .  ,  interceptor  flights)  encountered 
while  ingressing  or  egressing  from  their  assigned  targets.  No  attempt  is 
made  to  portray  offensive,  hostile  air  superiority  missions  by  the  threat. 

Interceptor  flights  operate  under  two  modes  of  control,  the 
CRC  mode  and  autonomous  mode.  In  the  CRC  mode,  specific  target  flights 
are  identified  by  the  CRC,  an  attempt  is  made  to  assign  airborne  inter¬ 
ceptor  flights  to  these  targets.  The  unassigned  interceptor  flight  which 
is  closest  to  the  target  and  which  has  an  intercept  capability  is  assigned 
to  the  target.  Only  one  interceptor  flight  is  assigned  against  each  target 
flight;  no  consideration  is  given  to  actual  size  of  either  interceptor  or 
target  flights.  Since  CRC's  have  imperfect  IFF,  the  target  flight  may  turn 
out  to  be  friendly;  in  this  event,  the  interceptor  flight  sends  a  message 
to  the  CRC  indicating  a  friendly  intercept/non-engagement,  as  discussed 
previously. 

In  the  event  that  interceptors  cannot  be  assigned  (either 
because  all  airborne  interceptors  are  assigned  or  because  unassigned 
airborne  interceptor  flights  cannot  achieve  or  intercept)  then  an  attempt 
will  be  made  to  assign  ground-air  assets  against  the  target.  A  concurrent 
request  will  be  made  by  the  CRC  to  its  subordinate  air  bases  to  launch 
available  interceptors.  Currently,  CRC's  hold  their  subordinate  inter¬ 
ceptor  assets  autonomously. 

Intercept  calculations  are  based  on  the  low  of  cosines, 
assuming  that  the  CRC  has  instantaneous  heading  and  velocity  (track) 
information  at  the  time  an  intercept  assignment  is  made,  and  also  assuming 
that  the  target  flight  will  maintain  its  heading  and  speed.  The  required 
condition  is  that  the  time  to  intercept  equal  the  flight  time  of  the  target 
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to  the  intercept  point;  this  result.,  in  the  equation  derived  in  the  figure. 
Once  an  interceptor  flight  has  been  assigned  to  a  target  by  the  CRC,  a 
continuous  recalculation  is  made  of  the  intercept  point,  and  the  inter¬ 
ceptor  flies  to  the  intercept  point  continuously.  The  intercept  assignment 
is  dropped  if  intercept  fails  to  remain  feasible. 

Interceptors  may  engage  targets  of  opportunity  whenever  they 
are  encountered,  either  in  the  course  of  an  intercept  assignment  before  the 
intercept  is  made  or  while  on  orbit.  In  the  autonomous  mode,  i.e.,  when 
the  CRC  is  destroyed,  all  air-air  engagements  are  against  targets  of 
opportunity  which  encounter  interceptors  on  air  patrol  orbits  near  air 
bases. 

b.  Surface  to  Air  Engagements 

After  an  initial  30  second  sighting  delay  for  a  new  track,  a 
CRC  attempts  to  assign  either  interceptors  or  ground-air  assets  against  the 
track.  Details  of  the  interceptor  assignment  process  are  discussed  in  the 
paragraph  on  air-air  processes.  When  interceptors  are  not  available  for 
assignment,  all  BOC's  with  a  nominal  capability  to  see  the  current  location 
of  the  target  flight  are  searched.  I  he  primary  criteria  for  assignment  of 
a  BOC  to  a  track  are: 

(1)  availability  of  the  BOC  to  accept  the  assignment; 

(2)  range  of  the  BOC  to  the  target  --  the  closest  available  BOC  is 
assigned; 

(3)  availability  to  the  BOC's  of  batteries  with  an  engagement  cap¬ 
ability  at  the  altitude  of  the  targets,  i.e.,  only  NIKE  HERCULES 
BOC's  are  assigned  to  high  altitude  targets,  and  only  HAWK  BOC's 
are  assigned  to  low  altitude  targets. 

If  a  BOC  is  currently  processing  less  than  30  tracks  and  is 
able  to  accept  an  assignment,  the  BOC  processes  the  track;  otherwise  a 
message  is  sent  to  the  CRC  indicating  that  the  BOC  is  not  ready.  In  the 
event  that  actual  line  of  sight  does  not  exist  to  the  target  (due  to 
stochastic  detection  events  or  terrain  masking)  the  track  is  tagged  as 
early  warning  information  and  an  expected  detection  event  is  scheduled. 
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Tracking  events  are  driven  by  flight  movements  in  much  the 
same  way  as  detections.  CRC's  continue  to  track  flights  as  it  perceives 
each  flight  movement.  Track  data  available  to  the  CRC  includes  latest 
track  update  time;  true  flight  heading  in  cartesion  coordinates  (i.e.,  ’iut 
between  low  level  hexes);  true  flight  velocity  and  true  flight  altitude 
At  each  track  update,  the  CRC  reviews  the  track  assignment  status. 
targets  which  are  viable  (i.e.,  not  east  bound)  and  which  are  assigned  t. 
interceptors,  new  interception  projections  are  made  and  messages  sent  tr. 
the  assigned  interceptor  flight.  There  are  no  limitations  to  the  trac* 
processing  capacity  of  the  CRC. 

For  tracks  detected  and  perceived  to  be  hostile  by  an  auto¬ 
nomous  BOC,  or  assigned  by  a  CRC  to  a  subordinate  BOC,  the  BOC  calculates  a 
projected  engagement  window  for  each  of  its  subordinate  batteries  against 
the  track.  Those  batteries  where  an  engagement  window  exists  are  put  on  a 
list  for  possible  assignment  against  the  track,  and  a  priority  is  cal¬ 
culated  for  the  track  by  the  BOC.  The  track  is  then  entered  into  a 
prioritized  list  of  active  tracks  being  processed  by  the  BOC. 

As  each  track  is  taken  from  the  prioritized  list,  the  list 
of  batteries  with  a  potential  engagement  window  against  the  track  is 
surveyed  to  determine  which  battery  has  the  latest  engagement  opportunity, 
in  order  to  determine  when  the  last  chance  for  engagement  of  the  track  by 
the  BOC  occurs.  Batteries  are  assigned  against  the  track  in  decreasing 
order  of  their  associated  ready  ammunition  until  a  user  specified  desired 
coverage  level  against  the  track  has  been  met;  the  number  of  batteries 
required  is  in  turn  based  on  the  actual  number  of  ready  fire  units  and 
available  ammunition  for  each  battery. 

Currently  only  immediate  (i.e.,  instantaneous)  processing  is 
played  in  MADEM;  however  the  option  exists  of  representing  BOC  and  battery 
processing  in  terms  of  a  single  server  queue  with  user  specified  processing 
times.  This  option  has  not  been  exercised  to  date.  In  the  autonomous 
mode,  the  BOC  assigns  all  of  its  resources  to  the  highest  priority  tracks; 
if  additional  tracks  are  present,  they  penetrate  without  being  engaged  by 
the  BOC. 


■  •».*, 
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For  tracks  detected  by  an  autonomous  battery,  or  assigned  to 
a  subordinate  battery  by  a  commanding  BOC,  the  battery  calculates  an 
engagement  window  for  the  track.  If  an  engagement  window  exists  and  it 
does  not  exceed  a  user  specified  threshold  response  time  (i.e.  ,  a  minimum 
required  engagement  window)  the  track  is  dropped.  Otherwise,  the  battery 
places  the  track  in  a  prioritized  list  of  all  active  tracks  which  it  is 
considering.  It  then  assesses  whether  the  assigned  target  can  be  tracked, 
considering  existence  of  line  of  sight,  and  maximum  tracking  range  for  the 
battery,  if  any.  For  cases  where  tracking  cannot  occur,  the  target  is 
dropped;  otherwise  the  battery  attempts  to  assign  ready,  available  fire 
units  against  the  track.  For  NIKE  HERCULES  and  HAWK  units,  with  capabilty 
for  engagement  of  a  single  track  at  a  time,  fire  units  are  allocated  until 
user  specified  desired  coverage  against  the  track  is  achieved  or  until  all 
resources  are  assigned.  For  systems  such  as  Patriot,  with  capability  for 
multiple  simultaneous  engagements,  a  running  total  of  simultaneous 
engagement  assignments  is  kept  for  the  battery;  engagements  are  assigned 
against  a  track  until  user  specified  desired  coverage  for  the  track  is 
achieved  or  until  all  engagement  capability  is  in  use. 

The  basic  processes  discussed  above  proceed  in  parallel  at 
the  CRC,  BOC  and  battery  level  as  tracking  of  a  target  continues.  As  the 
target  moves  and  changes  direction,  allocation  of  assets  is  shifted  to 
reflect  the  changing  conditions  as  a  function  of  all  of  the  other  tracks  in 
the  region. 

At  each  step  of  the  tracking  process  -  i.e.,  every  time  a 
target  flight  moves  --  batteries  tracking  the  target  evaluate  their 
engagement  opportunity. 

In  considering  an  engagement  attempt  against  a  track,  a 
battery  evaluates  the  current  target  altitude,  which  is  assumed  to  be 
available  as  part  of  the  track  data  (i.e.,  height  finding  processes  are  not 
modeled).  If  the  target  altitude  is  not  within  user  specified  engagement 
limits,  the  engagement  attempt  is  halted. 

For  cases  where  an  engagement  is  possible,  warhead  types  are 
chosen  to  be  launched.  Three  generic  systems  are  currently  considered  in 
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MADEM,  representing  HAWK,  NIKE  HERCULES  and  Patriot.  HAWK  fires  only 
conventional  ordnance;  thus  the  only  requirement  is  availability  of  ready 
ammunition.  Nike  Hercules  is  assumed  to  be  able  to  utilize  both  "large" 
and  "small"  yield  nuclear  warheads  and  conventional  warheads.  The  decision 
tree  for  munition  choice  is  shown  in  figures  I V- 1 7  and  IV- 18 .  The  user 
controls  the  total  pool  of  munitions  to  be  considered  --  i.e.,  for  a  con¬ 
ventional  only  case,  no  nuclear  munitions  are  specified  in  the  initiali¬ 
zation  data.  Patriot  is  assumed  to  have  a  capability  to  utilize  both 
conventional  and  "small"  yield  nuclear  warheads;  the  figure  shows  the 
decision  tree  for  munition  use  by  Patriot  units.  In  the  event  that  no 
appropriate  munition  is  available,  engagement  is  terminated. 

Where  engagement  processing  continues,  the  feasibility  of  an 
intercept  is  calculated.  This  involves  calculating  the  projected  intercept 
point,  if  one  exists,  and  insuring  that  all  engagements  take  place  within 
the  azimuth  and  range  limits  of  the  engagement  envelope  of  the  generic 
system.  Where  intercept  is  feasible,  an  intercept  time  is  calculated  and 
battery  firing  processes  are  scheduled. 

Two  fire  doctrines  are  considered,  shoot- 1 ook-shoot  and 
shoot-shoot  look.  Currently,  Nike  Hercules  and  Patriot  utilize  shoot- 
look-shoot  doctrines  against  all  targets;  HAWK  units  utilize  shoot-shoot- 
look  doctrine  until  the  fire  unit  engaging  the  target  has  less  than  2  ready 
missiles  or  the  battery  as  a  whole  has  less  than  9  missies.  HAWK  then 
transitions  to  the  shoot-look-shoot  doctrine.  Total  ammunition  status  is 
updated  at  both  the  fire  unit  and  battery  level  after  each  firing. 

Attrition  processes  are  based  on  a  single  replication  Monte 

Carlo  process,  using  user  specified  P^  functions  parameterized  on  range 

from  battery  to  target  for  each  of  the  ordnance/system  type  combinations. 

Each  missile  launch  is  assumed  to  be  independent  and  one  aircraft  kill  per 

missile  at  most  is  assumed,  i.e.,  no  multiple  hit/kill  per  burst  phenomena 

are  considered.  Instantaneous  kill  removal  occurs  in  MADEM;  i.e.,  P.  data 

k 

are  assumed  to  be  for  K=KILL  criteria. 

For  cases  where  nuclear  warheads  are  utilized,  prompt  com¬ 
munications  blackout  effects  are  treated.  Communications  are  cut  off  for 
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Figure  IV-17. 


NIKE-HERCULES  Ordnance  Selection 
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Figure  I V - 1 8 .  PATRIOT  Ordnance  Selection  Decision  Tree 
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all  players  located  in  the  same  9.45  km  hex  as  a  nuclear  burst  or  in 

adjacent  hexes.  For  CRC's  which  are  affected,  all  subordinates  (BOC's, 

interceptors  and  air  bases)  go  autonomous.  For  affected  BOC's  subordinate 

batteries  go  autonomous.  All  interceptors  in  the  affected  region  go  auto- 

3 

nomous.  Currently  no  reconstitution  capability  exists  for  C  processes, 
i.e.,  units  which  go  autonomous  remain  autonomous  thereafter.  No  other 
degradation  of  unit  effectiveness  due  to  nuclear  effects  are  considered, 
and  no  unintentional  fasticide  of  friendly  flights  is  played. 

HAWK,  Nike  Hercules  and  Patriot  units  all  assess  engagement 
outcomes  immediately.  The  engagement  will  continue  until  the  battery  has 
expended  all  of  its  ammunition,  the  battery  has  been  killed,  the  target 
flight  is  completely  destroyed,  or  the  target  flight  is  out  of  range. 
Coverage  against  the  track,  however,  may  be  altered  to  reflect  attrition  as 
well  as  changes  in  the  track  priority. 

Attrition  of  flights  due  to  ground  based  defenses  is  also 
exacted  by  short  range  air  defenses  (SHORADS).  However,  SHORAD  players  are 
aggregated  in  MADEM,  rather  than  being  explicitly  represented,  and  attri¬ 
tion  processes  are  coupled  to  flight  movement.  As  each  flight  moves  across 
a  hex  in  friendly  territory,  a  Pk  for  SHORAD  systems  is  determined  as  a 
function  of  the  flight's  altitude,  i.e.  , 

P^  =  [.01/Ln  (Altitude)]. 

A  single  replication  Monte  Carlo  process  is  then  utilized  to 
model  a  single,  independent  shot  by  SHORADS  systems  against  each  of  the 
aircraft  in  the  flight.  IFF  processes  are  also  considered  for  SHORADS, 
since  friendly  aircraft  are  effectively  recognized  as  friendly  90%  of  the 
time.  However,  hostile  aircraft  are  not  identified  as  friendly.  Removal 
cf  kills  is  immediate,  and  flights  may  be  totally  destroyed  by  SHORADS  as 
for  other  weapon  systems. 

c.  Air-Surface  Processes 

Air-surface  processes  in  MADEM  consist  of  execution  of 
attacks  by  flights  of  hostile  fighter  bombers  and  bombers  against  all 
friendly  surface  players  and  entities.  Surface  based,  friendly  players, 
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Figure  IV-19.  Directional  Engagement  Priorities 


including  CRC's,  BOC's  and  batteries,  are  all  at  risk  of  being  killed  by 
hostile  attacks;  however,  damage  from  multiple  attacks  is  not  accumulated 
for  these  players.  Damage  is  accumlated  for  friendly  air  bases;  however, 
no  degradation  of  airbase  operations  due  to  damage  is  considered.  All 
other  entities  in  MAOEM  act  as  sinks  for  hostile  attacks,  with  alternative 
priorities  for  the  Red  Planner;  damage  is  accumulated  for  these  targets 
based  on  the  number  of  attacks  made  against  them  and  the  ordnance  loads  of 
the  attacking  flights. 

As  part  of  the  attack  planning  process,  each  flight  of 
hostile  fighter  bombers  and  bombers  is  provided  with  a  planned  route  to  its 
target  and  the  hex  location  of  its  target.  Flights  which  successfully 
reach  the  target  hex  attempt  to  acquire  their  target.  Detection  is  prob¬ 
abilistic  based  on  a  single  replication  Monte  Carlo  process  for  each  air¬ 

craft  in  the  flight,  using  input  probability  of  detection  values  for  the 
target.  In  the  event  that  the  target  is  not  detected,  the  attack  is 

aborted  and  the  flight  returns  to  its  air  base.  No  unassigned  surface 
targets  of  opportunity  are  detected  or  attacked.  If  the  target  is 
successfully  detected,  an  attack  is  scheduled;  no  delay  times  from 
detection  to  attack  are  considered. 

The  attack  process  considers  attrition  due  to  terminal  area 
short  range  defenses  using  the  same  algorithm  as  discussed  in  the  section 
on  surface-air  processors.  Surviving  aircraft  deliver  all  of  their 

ordnance  on  the  target;  up  to  11  alternate  types  of  ordnance  can  be 
treated,  including  10  alternate  conventional  types  of  ordnance  and  1 
nuclear  type  of  ordnance. 
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SECTION  V 
MADEM  OPERATION 


A.  INTRODUCTION 

The  purpose  of  this  chapter  is  to  explain  the  operation  of  MADEM. 
Additional  information  on  MADEM  operations,  including  job  control  language 
files,  may  be  found  in  Appendices  D  and  E  of  this  manual  and  in  Appendix  A 
of  the  MADEM  Programmer  Manual. 

MADEM  is  currently  configured  for  operation  on  the  Air  Force  Weapons 
Laboratory  (AFWL)  computer  system.  Since  many  aspects  of  MADEM  operation 
(including  the  three  processor  configuration  discussed  in  the  following 
section)  are  direct  results  of  AFWL  system  requirements,  the  user  should 
pay  particular  attention  to  Appendix  D  before  attempting  to  run  MADEM.  The 
user  should  also  be  aware  that  MADEM  can  be  reconfigured  to  run  on  other 
CDC  systems  with  minimal  modification. 

6.  SOFTWARE  COMPONENTS 

MADEM  has  three  major  software  components  --  a  preprocessor,  a  main 
processor,  and  a  postprocessor.  The  overall  configuration  of  these  pro¬ 
cessors  and  their  input  and  output  files  is  illustrated  in  Figure  V-l. 

The  preprocessor  (sometimes  referred  to  as  INITBIN)  reads  user  inputs, 
which  include  the  data  base  and  Red  Threat  planning  specifications,  and 
carries  out  che  Red  Threat  planning  process.  The  resulting  Red  Attack  plan 
is  then  saved  on  a  "HOLD  FILE"  for  subsequent  use  by  the  main  processor. 
In  addition  to  the  "HOLD  FILES"  the  preprocessor  also  outputs  a  printed 
summary  of  the  Red  Attack  plan  and  a  "HISTORY  FILE".  The  HISTORY  FILE 
contains  a  record  of  unit  creation  events  which  can  be  used  by  the  post¬ 
processor  to  construct  summary  tables  of  the  types  of  units  created. 

The  main  processor  (sometimes  referred  to  as  RUNBIN)  is  used  to  simu¬ 
late  the  actual  combat  processes  which  result  from  the  Red  attack.  The 
main  processor  is  run  in  a  cyclical  fashion.  The  initial  main  processor 
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Figure  V-l.  MADEM  Processor  Configuration 
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run  is  made  using  the  Red  Attack  Plan  HOLD  FILE  as  input.  Combat  processes 
are  then  carried  out  for  approximately  one  hour  of  game  time  after  which 
execution  is  terminated  and  HOLD  FILES  are  created  containing  the  status  of 
all  units  at  the  end  of  the  hour.  This  HOLD  FILE  then  becomes  the  input 
for  the  next  main  processor  cycle.  Each  of  these  main  processor  cycles  is 
referred  to  as  a  volume.  As  many  volumes  can  be  run  as  are  required  to 
simulate  the  desired  duration  of  conflict.  The  main  processor  also  outputs 
an  event  trace  and  a  history  file.  The  event  trace  records  all  of  combat 
events  which  occurred  during  the  volume.  The  HISTORY  FILE  contains  a 
record  of  key  events  which  can  be  used  by  the  postprocessor  to  summarize 
the  battle. 

The  postprocessor  (sometimes  refered  to  as  H I STB I N )  reads  HISTORY 
FILES  output  by  the  preprocessor  and  main  processor  and  outputs  a  variety 
of  tabular  summaries  of  the  battle.  These  outputs  include  the  following: 

•  Red  aircraft  acquired  by  Blue  defense  units 

•  Red  aircraft  engaged  by  Blue  defense  units 

•  Red  aircraft  damaged  by  Blue  defense  units 

•  Blue  units  damaged  by  Red  aircraft 

•  Weapon  system  expenditures  by  unit  type 

•  Number  of  Red  aircraft  to  reach  targets 

•  Number  of  units  created  by  type. 

C.  PREPROCESSOR  ( INITBIN) 

MADEM's  preprocessor  (INITBIN)  requires  three  primary  inputs  to  carry 
out  Red  threat  planning:  a  set  of  Run  Parameter  Cards,  a  Data  Base  File 
and  a  User  Input  Language  File.  Each  of  these  required  inputs  is  described 
in  detail  in  the  following  sections. 

1 .  Run  Parameter  Cards 

The  Run  Parameter  Cards  control  the  preprocessor  run.  There  are 
two  card  types.  The  first  is  mandatory.  The  second  is  optional.  The 
formats  of  these  cards  are  listed  below: 
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CARD  1:  (UNFORMATTED,  MANDATORY) 

PARM  1  -  Must  be  Integer  1  for  INITBIN 

PARM  2  -  INTEGER,  SIZE  OF  ISPACE  (MAX)  during  INITBIN  (50000) 

PARM  3  -  Max  number  of  players  on  either  side 
PARM  4  -  Dummy  Value  (25) 

PARM  5  -  Dummy  value  (999999) 

PARM  6  -  Dummy  value  (1) 

CARD  2  TO  THE  LAST  CARD: 

The  second  set  of  options  are  all  optional.  Each  of  these  parameters 
must  begin  in  column  1.  There  may  be  only  1  Parm  Per  card,  with 
as  many  cards,  as  are  necessary.  It  is  recommended  that  these 
options  be  used  only  when  debugging. 

PARMS: 

'DEBUG=0N'  -  Turns  on  full  debug  mode 
'DUMP=0N'  -  Will  dump  ISPACE  at  end  of  run. 

'DATFLE=0N'  -  Turns  on  display  of  OATFILE  data  structure. 

' ST0P-00AT'  -  Stop  INITBIN  after  DATFILE 
' ST0P=U0IL‘  -  Stops  INITBIN  after  SEMANT  (UOIL) 

'ST0P=DEL‘  -  Stop  INITBIN  after  DELADD,  before  executing 
plan  event. 

'REC0VR=0FF'  -  Turns  off  system  recovery  routine 

EXAMPLE: 

1,500000,600,25,  999999,  1 

DEBUG=0N 

DUMP=0N 

0ATFILE=0N 

ST0P=0DAT 

2.  Data  Base  File  (DATFILE) 

The  Data  Base  File  contains  basic  specifications  for  all  of  the 
player  units  in  MADEM  as  well  as  probability  of  kill  and  probability  of 
detection  tables.  It  consists  of  a  scenario  title  card  and  a  series  of 
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data  class  code  cards  along  with  their  associated  specification  cards.  The 
number  and  format  of  the  specification  cards  will  vary  with  class  code. 

The  first  card  in  the  Data  Base  File  must  be  a  Scenario  Title 
Card.  This  card  may  contain  an  up  to  70  character  description  of  the 
scenario  to  which  the  data  base  applies.  This  description  will  become  the 
header  for  the  preprocessor  printed  output. 

The  Title  Card  is  followed  by  a  series  of  13  classes  cf  data. 
Each  class  consists  of  a  Class  Code  Card  followed  by  a  series  of  Specifi¬ 
cation  Cards.  The  data  classes  must  be  inserted  in  the  following  order: 


(1) 

CLASS  CODE 

6026 

DESCRIPTION 

Air  Defense  Site  Data  Base 

(2) 

6006 

Unit  acquisition  range  information 

(3) 

6004 

Payload  data  base 

(4) 

6003 

Aircraft  data  base 

(5) 

6005 

FI ight  profi les 

(6) 

6002 

FI ight  speci f i cations 

(7) 

6001 

Formation  specifications 

(8) 

6007 

Air  base  queue  specifications 

(9) 

6008 

Initial  assignment  of  aircraft  to 

(10) 

6101 

air  bases. 

Air  to  air  probability  of  kill 

01) 

6102 

Air  to  ground  probability  of  kill 

(12) 

6103 

SAM  probability  of  kill 

(13) 

6201 

Air-to-air  probability  of  death 

Each  class  of 

data  will  be 

shown  separately  to  define  the  varying 

input  formats  for  each. 

Basical ly , 

all  classes  will  consist  of  one  class 

code  card 

followed  by 

speci f ication 

cards  that  are  unique  to  each  class. 

The  forma 

..  for  each  card  is  defined  below.  On  all  cards,  each  field  is 

separated 

by  a  comma. 

Fields  which 

are  labeled  model  value  are  non-user 

specified  but  are  required  for  proper  operation  of  the  model. 


CLASS  6026 


Air  Defense  Site  Data  Base 

Class  Code  Card 


Field 

Title 

Description 

1 

CARDS 

Number  of  items  in 

class 

2 

CLASS 

Class  number,  must 

be  6026 

Specification  Cards 

For  each  item  in  this  class,  three  cards  are  required  and  follow  the 
format  of  cards  A,  B,  and  C  described  below.  Typically,  there  are  six 
items  in  this  class,  each  requiring  three  cards  for  a  total  of  eighteen 
specification  cards. 


Card  A  Format: 

Field 

Title 

Description 

1 

TYPE 

Unit  type  number 

150  =  HAWK  BOC 

155  =  Patriot  BOC 

160  =  Here  BOC 

170  =  HAWK  Battery 

175  =  Patriot  Battery 

180  =  Here  Battery 

2 

MODVAL  1 

Model  value  =  1 

3 

MAXIMUMD1GEST 

Maximum  number  of  flights  on  which 
unit  can  be  digesting  information 
at  any  one  time.  Applies  to  BOC 

and  BTRY. 

4 

MAXTIMEDIGEST 

Desired  interval  between  digestion  ' 
information  on  a  particular  track  ii 

seconds.  Applies  to  BOC  and  BTRY. 

5 

MINTIMEDIGEST 

Minimum  time  between  consecutive 

digests  in  seconds.  Applies  to  BOC 

and  BTRY. 
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6 


LOSTTIME 


Time  after  which  a  track  not  seen  is 
assumed  permanently  lost  in  seconds. 
Applies  to  BOC  and  BTRY. 

7  LASTCHANCE  Time  considered  short  for  a  subordinate 

to  respond  to  a  target  in  seconds 
(time  from  now  until  his  last  chance 
to  shoot)  for  BOC.  For  battery  this 
is  Model  Value  =  0. 


8  ENGAGEWINDOW  Minimum  length  of  subordinates  engage¬ 

ment  window  for  a  significant  engage¬ 
ment  opportunity  in  seconds.  Applies 


to  BOC  and  BTRY. 

9 

MODVAL  2 

Model  Value  =  0 

10 

MODVAL  3 

Model  Value  =  0. 

Card  B  Format: 

Field 

Title 

Description 

1 

C0V0N0NE 

Desired  number  of  fire  units  coverage 

for  one  aircraft.  Applies  to  BOC  and 

BTRY. 

2 

ONE 

Model  Value  =  1 

3 

C0V0NFEW 

Desired  number  of  fire  units  coverage 

for  few  aircraft.  Applies  to  BOC  and 

BTRY. 

4 

FEW 

Model  Value  =  5 

5 

C0V0NMANY 

Desired  number  of  fire  units  coverage 
for  many  aircraft.  Applies  to  BOC 

and  BTRY. 

6 

MANY 

Model  Value  -  1000000 

7 

TIMEFIIGHT 

Maximum  time  of  flight  for  missile 

in  seconds.  Applies  to  BOC  and  BTRY. 

8 

MI SS I LERANGE 

Maximum  range  for  missile  in  meters. 

Applies  to  BOC  and  BTRY. 
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Card  B 

Format: 

(Conti nued) 

Field 

Title 

Description 

9 

MAXASSIGN 

Maximum  number  of  targets  per  ready 
fire  unit  to  be  assigned  at  one  time 

for  BOC.  For  BTRY  Model  Value  =  0 

10 

MODVAL  4 

For  BOC,  Model  Value  =  8 

For  BTRY,  Model  Value  =  11 

11 

MODVAL  5 

Model  Value  =  0. 

12 

MAXTRACKRANGE 

For  BTRY,  maximum  tracking  range  in 
meters  for  BOC,  Model  Value  =  0. 

13 

LOCKONTIME 

For  BTRY,  assumed  time  to  achieve 
lockon  in  seconds.  For  BOC,  Model 

Value  =  0. 

Card  C 

Format: 

Field 

Title 

Description 

1 

MODVAL  6 

Model  Value  =  0. 

2 

MODVAL  7 

Model  value  =  0. 

3 

C0NVL0AD 

Number  of  missiles  with  conventional 

warheads. 

-  IF  HAWK,  number  of  missiles  with 
conventional  warheads  per  fire  unit 
(half  the  number  per  battery) 

-If  NIKE  HERCULES,  number  of  missiles 
with  conventional  warheads  per  fire 
unit  (per  battery) 

-IF  PATRIOT,  number  of  missiles  with 
conventional  warheads  per  battery. 

4  SNUKELOAD  Number  of  missiles  with  nuclear 

warheads. 

-  IF  HAWK  must  be  0 

-  IF  NIKE  HERCULES,  number  of  missiles 
with  small  nuclear  warheads 

-  IF  PATRIOT  number  per  battery 
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Card  C  Format: 

Field 

5 


6 


7 


8 


10 


11 


EXAMPLE: 

2,  6026 
160,  1,  3,  30, 
1,  1,  2,  5,  3, 
0. ,  0. ,  0,  0, 
180,  1 ,  3,  30, 
1,  1,  2,  5,  3, 
0. ,  0. ,  14,  0, 


(Conti nued) 
Title 
LNUKELOAD 


CVRESUPPLYFREQ 


RESUPPLYCV 


SNRESUPPLYFREQ 


LNRESUPPLYFREQ 


RESUPPLYLN 


Description 

Number  of  missiles  with  large  nuclear 
warheads 

-  If  HAWK  must  be  0 

-  IF  NIKE  HERCULES,  number  with  large 
nuclear  warheads 

-  IF  PATRIOT,  must  be  0. 

Time  between  resupply  of  conventional 
ammo  in  seconds  for  battery. 

IF  B0C,  Model  Value  =  0. 

Number  of  missiles  per  resupply 
for  conventional  ammo  for  battery. 

IF  B0C,  Model  Value  =  0. 

Time  between  resupply  of  small  nuke 
ammo  in  seconds  for  battery. 

-  IF  B0C,  Model  Value  =  0. 

Time  between  resupply  of  large  nukes 
in  seconds  for  battery. 

If  B0C,  Model  Value  =  0. 

Number  of  missiles  per  resupply  for 
large  nukes  if  battery 


(Class  Code  Card) 


15,  75. ,  37. ,  10. ,  0. ,  0.  (Card  A) 

1000000,  90.,  150000.,  1,  8,  5,  5.,  5.  (Card  B) 

,  0,  0,  0,  0,  0,  0  (Card  C) 

15,  75. ,  0. ,  10. ,  0. ,  0.  (Card  A) 

1000000,  90.,  150000,  0.,  11,  0,  180000. , 1 5. (Card  B) 

0,  21600,  2,  0,  0,  0,  0  (Card  C) 
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CLASS  6006 


Unit  Acquisition  Range  Information 


Class  Code  Card 


Field 

Title 

Description 

1 

CARDS 

Number  of  items  in 

class 

2 

CLASS 

Class  number,  must 

be  6006 

Specification  Card 

For  each  item  in  this  class,  one  card  is  required  and  follows  the 
format  described  below.  Typically  there  are  four  items  in  this  class, 
each  requiring  one  card  for  a  total  of  four  specification  cards. 

Field  Title  Description 

1  TYPE  Unit  type  number 

2  RANGE  Acquisition  range  in  meters 


EXAMPLE: 

4,  6006 
220,50000. 
130,200000. 
400,  60000. 
160,  200000 


(Class  code  card) 

(Class  description  card) 
(Class  description  card) 
(Class  description  card) 
(Class  description  card) 
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CLASS  6004 
Payload  Data  Base 


Class  Code  Card 
Field 


Title 


Description 

Number  of  payload  types  in  this  class 
Class  number,  must  be  6004 


1  CARDS 

2  CLASS 
Specification  Cards 

For  each  item  in  this  class,  two  cards  are  required  and  follow  the 
format  of  cards  A  and  B  described  below.  There  must  be  an  A  card  for  each 
item  and  as  many  8  cards  as  designated  in  field  number  2  of  card  A. 

Card  A  Format: 

Title 


Field 

1 


ICLASS 


INUM 


Description 

Payload  type  identification  number 
Must  be  3  for  air  to  ground 
Must  be  4  for  air  to  air 
Number  of  items  of  this  type  to 
follow 


Card  B  Format: 

Field  Title  Description 

1  INDEX  Identification  number,  must  be  unique 

identifier  within  this  payload 
type. 


EXAMPLE: 

2,  6004 

3,  3 
1 

2 

3 

4,  1 
1 


(Class  code  card) 
(Card  A) 

(Card  B) 

(Card  B) 

(Card  B) 

(Card  A) 

(Card  B) 
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CLASS  6003 


Aircraft  Data  Base 

Class  Code  Card 


Field 

Title 

Description 

1 

CAROS 

Number  of  items  in  the 

class 

2 

CLASS 

Class  number  -  must  be 

6003 

Specification  Cards 

For  each  item  in  this  class,  two  cards  are  required  and  follow  the 
format  of  cards  A  and  B  described  below.  There  is  one  item  in  this  class 
for  each  aircraft  type. 

Card  A  Format: 


Field 

1 


2 

3 

4 

5 

6 


Title 

TYPE 


MAXSPEED 

CRUISESPEED 

MAXALTITUDE 

MINALTITUOE 

MAXCLIMBDIVE 


Description 
Aircraft  type  number 
401-419  BLUE  interceptors 
420-439  RED  fighters 
440-459  RED  fighter/bombers 
460-479  RED  bombers 
Maximum  speed  in  meters/seconds 
Cruising  speed  in  meters/seconds 
Maximum  altitude  in  meters 
Minimum  altitude  in  meters 
Maximum  climb/dive  rate  in  meters/ 


seconds 


Card  B  Format: 

Field  Title  Description 


1  FUELC0NSUME 

2  ACQRANGE 

3  RADARCS 

4  ATTACKRADIUS 

5  MAXFUEL 
EXAMPLE: 

1 ,  6003 

460,  420,  280. ,  15000.  ,  100.  , 
1. ,  60000.  ,  10. ,  800000.  ,  200. 


Fuel  consumption  rate  hex/second 
Acquisition  range  in  meters 
Radar  ARC 

Attack  radius  in  meters 
Maximum  fuel  load 

(Class  Code  Card) 

1500.  (Card  A) 

(Card  B) 
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CLASS  6C05 
Flight  Profiles 


Class  Code  Card 


Field 

Title 

Description 

1 

CARDS 

Number  of  items  in 

class 

2 

CLASS 

Class  number,  must 

be  6005 

Specif icaton  Cards 

For  each  item  in  this  class,  one  card  is  required  and  follows  the 
format  described  below.  Typically  there  are  four  items  in  this  class,  each 
requiring  one  card  for  a  total  of  four  specification  cards. 


Field 

Title 

Description 

1 

TYPE 

Profile  identication  number 

2 

ALTCREN 

Altitude  of  first  leg  in  meters 

3 

ALT0TGT 

Altitude  of  second  leg  in  meters 

4 

ALT0AB 

Altitude  of  third  leg  in  meters 

EXAMPLE: 

2,  6005 

(Class  code  card) 

1,  10000. 

,  10000.,  10000. 

(Class  description  card) 

2,  5000.  , 

500.  ,  5000. 

(Class  description  card) 

Ill 
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CLASS  6002 

Flight  Specifications 

Class  Code  Card 


Field 

Title 

Description 

i 

CARDS 

Number  of  items  in 

this  class 

2 

CLASS 

Class  number,  must 

be  6002 

Specification  Cards 

For  each  item  in  this  class,  two  cards  are  required  and  follow  the 
format  of  cards  A  and  B  described  below.  There  must  be  one  A  card  for  each 
flight  type  and  as  many  8  cards  as  designated  in  Field  number  9  of  card  A. 


Card  A 

Field 

Format: 

Title 

Description 

1 

TYPE 

Flight  specification  number 

2 

IACTYPE 

Aircraft  type  number  (400  series) 

3 

MAXNOAC 

must  match  a  number  in  class  6003, 

card  A,  field  1 

Maximum  number  of  aircraft  in  flight 

4 

MINOAC 

Minimum  number  of  aircraft  in  flight 

5 

MULTAC 

Multiples  of  aircraft  required  for 

6 

PROFILE 

fl ight 

Profile  identification  number  for 

7 

SPFLTC 

this  flight.  Must  match  an  ID 

number  in  field  one  of  a  class 

6005  specification  card. 

Flight  cruising  speed  in  meters/seconds 

8 

DISTSEP 

Flight  separation  distance  in  meters 

9 

NOPAYS 

Number  of  payloads 

Card  B 

Field 

Format: 

Title 

Description 

1 

IPAYTYP 

Payload  type  identification  number 

2 

MAXAMT 

(3  or  4) 

Maximum  number  of  loads  of  this  payload 

3 

MINAMT 

Minimum  number  of  loads  of  this  payload 
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4 


EXAMPLE: 

1,  6002 
7,  401,  4,  2, 
4,  2,  2,  1 
4,  2,  2,  2 
4,  4,  4,  3 


IPAY1D  Identification  number  of  particular 

payload  within  type.  Must  match  a 
number  in  field  one  of  card  8, 
class  6004. 

(Class  Code  Card) 

2,  4,  350.  ,  500. ,  3  (Card  A) 

(Card  B) 

(Card  B) 

(Card  B) 
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CLASS  6001 

Formation  Specifications 


Class  Code  Card 
Field 


Specification  Cards 


Title 

CARDS 

CLASS 


Description 

Number  of  items  in  this  class 
Class  number,  must  be  6001 


For  each  item  in  this  class,  at  least  two  cards  are  required  and 
follow  the  format  of  cards  A  and  B  described  below.  There  must  be  one  card 
A  for  each  formation  type  and  as  many  B  cards  as  designated  in  field  number 
3  of  card  A. 


Card  A  Format: 
Field 


Title 


SPFORMC 


NOFLTS 


Description 
Formation  type  number 
Formation  cruise  speed  in  meter"/ 
seconds 

Number  of  flights  in  formation  * 


Card  B  Format: 
Field 


Title 

IDFLITE 


Description 

Flight  specification  number  must 
match  a  number  in  class  6002, 
card  A,  Field  1 


EXAMPLE: 

1,  6001 
4,  350. ,  3 


(Class  Code  Card) 
(Card  A) 
(Card  B) 
(Card  B) 
(Card  B) 
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CLASS  6007 

Air  Base  Queue  Specifications 


Class  Code  Card 

This  class  code  is  not  implemented  at  this  time,  all  values  are  MODEL 
VALUES. 


EXAMPLE: 

1,  6007 

1 ,  .005,  0. ,  .2 


(Class  Code  Card) 

(Class  description  card) 


CLASS  6008 


Initial  Assignment  of  Aircraft  to  Air  Bases 


Class  Code  Card 
Field 
1 
2 


Title 

Description 

CARD 

Number  of  items  in 

this  class 

CLASS 

Class  number,  must 

be  6008 

Specification  Cards 

For  each  item  in  this  class,  two  cards  are  required  and  follow  the 
format  of  cards  A  and  B  described  below.  There  must  be  an  A  card  for  each 
item  and  as  many  B  cards  as  designated  in  field  number  2  of  card  A. 


Card  A  Format: 

Field 

Title 

Descri pti on 

1 

IDAB 

Air  Base  number 

2 

NDACTYPES 

Number  of  aircraft  types  on 

air  base 

note:  Limit  of  1  for  Blue 

(multiple  air  bases  may  be 

air  bases 

col  located 

) 


Card  B  Format: 
Field 
1 
2 
3 


EXAMPLE: 

2,  6008 
19,  2 

460,  34,  0 
440,  17,  0 
15,  1 

401  ,  11  ,  4 


Title 

ACTYPE 

NUMACRFT 

F0RMTYPE 


Description 

Aircraft  type  number  (400  series) 
Number  of  aircraft 
Formation  type  number 

-  required  for  blue  air  bases,  and 
must  match  class  6001,  card  A, 
field  1 . 

-  equals  zero  for  red  air  bases 


(Class  Code  Card) 
(Card  A) 
(Card  B) 
(Card  B) 
(Card  A) 
(Card  B) 
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CLASS  6101 

Air  to  Air  Probability  of  Kill 


Class  Code  Card 
Field 


Specification  Cards 


Title 

CARDS 

CLASS 


Description 


Number  of  cards 


Class  number,  must  be  6101 


For  each  item  in  this  class,  one  card  is  required  and  follows  the 
format  described  below.  At  present  there  is  only  one  item  in  this  class, 
each  requiring  one  card  for  a  total  of  one  specification  cards. 

Field  Title  Description 

1-8  . PK  Air  to  air  ordnance  probability 

kill. 


EXAMPLE: 

1,  6101 

.1,  .2,  .3,  .4,  .5,  .6,  .7,  .8 


(Class  Code  Card) 
(Card  A) 


CLASS  6102 


Air  to  Ground  Probability  of  Kill 

Class  Code  Card 

Field 

Title 

Description 

1 

CARDS 

Number  of  cards 

2 

CLASS 

Class  number,  must  be  6102 

Specification  Cards 

For  each  item 

in  this 

class,  one  card  is  required  and  follows  the 

format  described  below.  At 

present  there  are  26  items,  and  each  card 

having  11  fields  forms  a  26  X 

1 1  array. 

Field 

Title 

Description 

1-11 

PK 

Probability  of  kill  tables 

EXAMPLE: 

26,  6102  (Class  Code  Card) 


0. 

o. , 

•  2, 

•  1  , 

.9, 

.04, 

02, 

26, 

31, 

.33,  .4 

(Class 

description 

card) 

0. 

0-  , 

0.  , 

o. , 

.21 

.33, 

.01, 

■  12, 

■2, 

.35 

(Class 

descript  ion 

card) 

0. 

o. , 

o. , 

o. , 

.21 

•  33, 

•  01, 

.12, 

•2, 

.35 

0. 

0. 

0.  , 

0.  , 

o. , 

0.,  0 

,  0. 

0., 

o. , 

0.  ,  0. 
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CLASS  6103 

Surface-to-Ai r  Probability  of  Kil 


Class  Code  Card 
Field 


Title 

CARDS 

CLASS 


Descri pti on 
Must  Equal  9 

Class  Number,  must  be  6103 


Specification  Cards 


The  equation  to  derive  the  probability  of  kill  (PK)  for  surface  to  air 
missiles  (SAM)  is:  PK  =  A+B(R).  The  coeffeicients  in  the  equation  A  and  B 
are  used  as  inputs  in  the  datfile.  They  are  values  that  are  derived  from 
the  combination  of  3  missile  types  and  3  ordinance  types. 


Field 


Title 

SAMPKA 

SAMPKB 


Description 

For  a  missile  type  and  ordinance  type 
For  the  same  missile  type  and  ordinance 
type 


EXAMPLE: 

9,  6103 
.447,  -.01 E- 5 
.536,  -4.0685E-6 
.310,  -1.6636E-6 
.00,  0.0 

.96,  -1.004787E-6 
.80,  0.0 
.00,0.0 
.00,  0.0 
.90,  0.0 


(Class  Code  Card) 

A ,  B  for  Missile  Type  1  , 
A,  B  for  Missile  Type  2, 
A,  B  for  Mi ssi 1 e  Type  3 , 
A,  B  for  Mi ssi le  Type  1 , 
A,  B  for  Missile  Type  2, 
A,  B  for  Missile  Type  3, 
A,  B  for  Missile  Type  1 , 
A,  B  for  Missile  Type  2 , 
A ,  B  for  Mi ssi 1 e  Type  3 , 


Ordnance 

Ordnance 

Ordnance 

Ordnance 

Ordnance 

Ordnance 

Ordnance 

Ordnance 

Ordnance 


Type  1 
Type  1 
Type  1 
Type  2 
Type  2 
Type  2 
Type  3 
Type  3 
Type  3 
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CLASS  6201 

Ai r-to-Ground  Probability  of  Death 


Class  Code  Card 


Field 

Title 

Description 

1 

CARDS 

Number  of  cards 

2 

CLASS 

Class  number,  must  be  6201 

Speci fi cation 

Cards 

For  each 

i  tem 

in  this  class, 

one  card  is  required  and  follows  the 

format  described  below.  At  present  a  maximum  of  ten  cards  are  allowed. 

Field 

Title 

Description 

1-8 

PD 

Air  to  ground  probability  of  death. 

EXAMPLE: 

10,  6201 

(Class  Code  Card) 

.68,0,  0. 

,  o., 

.84,  1. ,  68,  .68 

(Class  Description  Card) 

1. ,  .68, 

0.  ,  0, 

.  ,  0. ,  0.  ,  .  68 ,  0 

(Class  Description  Card) 

0.,  0.,  . 

68,  0. 

.,  .68,  0.,  0.,  1, 

(Class  Description  Card) 

0. ,  0.,  0.,  0.,  0.,  0.,  0.,  0.  (Class  Description  Card) 


3. 


User  Input  Language  File 

The  User  Oriented  Input  Language  File  (UOIL)  specifies  the 
scenario  to  be  played.  This  specification  consists  of  a  list  of  commands 
(stated  in  the  user  oriented  input  language  described  below)  which  indi¬ 
cates  the  positions  of  various  units,  the  command/control  relationships  of 
the  units  and  the  structure  of  the  Red  Threat  Plan.  Allowable  commands, 
along  with  their  proper  syntax,  are  listed  below.  Each  sentence  is  com¬ 
posed  of  two  types  of  words:  constants  and  variables.  Some  constants  and 
variables  have  optional  plurals  and  abbreviations  that  are  shown  below. 
The  variable  options  are  listed  below  each  sentence  by  words  in  all  capital 
letters.  For  a  complete  example  of  an  input  language  file  see  the  test 
case  in  Chapter  V  of  this  manual. 

•  NUMBER  UNITTYPE  commands  NUMBER  UNITTYPE. 


Where  NUMBER  =  An  integer  NUMBER 
Where  UNITTYPE  =  HAWK.BTRY 

HERCBTRY 

PATBTRY 

HAWKBOC 

HERCBOC 

PATBOC 

CRC 

AIRBASE 

TAB 

AWACS 

LANCE 

HJ 

BRIDGE 

DEPOS 

PERSHING 

POL 

SASP 
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ASP 

RESERVES 

TRAINS 

CLVBTRY 

VIIIBTRY 

CORPBTRY 

CORPCP 

DIVCP 

SOC 

ATAF 

Optional  Plurals:  HAWKBTRY  =  HAWKBTRYS 

HERCBTRY  =  HERCBTRYS 
AIRBASE  =  AIRBASES 
SASP  =  SASPS 
ASP  =  ASPS 
RESERVE  =  RESERVES 
TRAIN  =  TRAINS 
CLVBTRY  =  CLVBTRYS 
VIIIBTRY  =  VI I IBTRYS 
CORPCP  =  CORPCPS 
DIVCP  =  DIVCPS 

ional  Abbreviations:  CRC  =  CRP 

CRC  =  GP 
CRC  =  GRDUP 
CRC  =  MCC 
AIRBASE  =  AB 
commands  =  cmds 
commands  =  c 


122 


Example: 

99  ATAF  commands  1  CRC. 

1  CRC  cmds  4  HAWKBOC. 

3  HAWKBOC  cmds  28  HAWKBTRY. 


Hex  NUMBER  has  altitude  NUMBER  LUNIT. 

Where  NUMBER  =  An  integer  NUMBER 
Where  LUNIT  =  FEET 
METERS 

Optional  Abbreviations:  altitude  =  alt 

feet  =  ft 
meters  =  m 

Example: 

Hex  7752352  has  altitude  300  feet. 
Hex  7753413  has  alt  400  m. 


Buffer  zone  width  is  NUMBER  km. 
Where  NUMBER  =  An  integer  NUMBER 
Example: 

Buffer  zone  width  is  40  Km. 


Random  seed  is  NUMBER. 


Where  NUMBER  =  An  integer  NUMBER 


Example: 

Random  seed  is  16. 


•  SIDE. 


Where  SIDE  =  BLUE 
NATO 
RED 
PACT 


Example: 

BLUE. 

PACT. 


•  Wave  NUMBER  start  time  is  NUMBER  hours  onday  NUMBER  for  NUMBER  minutes 
with  NUMBER  target  types. 

Where  NUMBER  =  An  integer  NUMBER 

Optional  Abbreviations:  hours  =  hrs 

minutes  =  min 
onday  =  day 


Example: 

Wave  1  start  time  is  0630  hrs  day  1  for  5  min  with  5  target  types. 
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Target  type  unittype  NUMBER  formation  NUMBER  NUMBER  km  range  limits. 
Where  UNIT  TYPE  =  HAWKBTRY 

HERCBTRY 

PATBTRY 

HAWKBOC 

HERCBOC 

PATBOC 

CRC 

AIRBASE 

TAB 

AWACS 

LANCE 

HJ 

BRIDGE 

OEPOS 

PERSHING 

POL 

SASP 

ASP 

RESERVES 

TRAINS 

CLVBTRY 

VIIBTRY 

CORPBTRY 

CORPCP 

OIVCP 

soc 

ATAF 


Where  NUMBER  =  An  integer  NUMBER 

Optional  Plurals:  HAWKBTRY  =  HAWKBTRYS 

HERCBTRY  =  HERCBTRYS 


AIRBASE  =  AIRBASES 
SASP  =  SASPS 
ASP  =  ASPS 
RESERVE  =  RESERVES 
TRAIN  =  TRAINS 
CLVBTRY  =  CLVBTRYS 
VIIIBTRY  =  VII IBTRYS 
CORPCP  =  CQRPCPS 
DIVCP  =  DIVCPS 
formation  =  formations 

Optional  Abbreviations:  CRC  =  CRP 

CRC  =  GP 
CRC  =  GROUP 
CRC  =  MCC 
AIRBASE  =  AB 

Example: 

Target  type  HAWKBTRYS,  1  formation  90,  0  km  range  limits. 

Target  type  PERSHING,  1  formation  200,  50  km  range  limits. 


Target  NUMBER1  unittype  is  at  NUMBER2  latitude  NUMBER2 
longitude. 

Where  NUMBER1  =  An  interger  target  ID  number 
Where  NUMBER2  =  A  real  decimal  degree 
Where  UNITTYPE  =  HAWKBTRY 

HERCBTRY 

PATBTRY 

HAWKBOC 

HERCBOC 

PATBOC 


AIRBASE 

TAB 

AWACS 

LANCE 

HJ 

BRIDGE 

DEPOS 

PERSHING 

POL 

SASP 

ASP 

RESERVES 

TRAINS 

CLVBTRY 

VIII BTRY 

CORPBTRY 

CORPCP 

DIVCP 

soc 

ATAF 

HAWKBTRY  =  HAWKBTRYS 
HERCBTRY  =  HERCBTRYS 
AIRBASE  =  AIRBASES 
SASP  =  SASPS 
ASP  =  ASPS 
RESERVE  =  RESERVES 
TRAIN  =  TRAINS 
CLVBTRY  =  CLVBTRY 
VIIIBTRY  =  VI I IBTRYS 
CORPCP  =  CORPCPS 


DIVCP  =  DIVCPS 
latitude  =  latitudes 
longitude  =  longitudes 


Optional  Abbreviations:  CRC  =  CRP 

CRC  =  GP 
CRC  =  GROUP 
CRC  =  MCC 
AIRBASE  =  AB 
latitude  =  lat 
longitude  =  long 


Examp  1 e : 

Target,  23  SASP  is  at  50.0  lat,  8.4 
Target,  27  TRAIN  is  at  48.9  lat,  10. 


•  Target  NUMBER  UNITTYPE  is  at  hex  NUMBER. 
Where  NUMBER  =  An  integer  NUMBER 

I 

Where  UNITTYPE  =  HAWKBTRY 

HERCBTRY 

PATBTRY 

HAWKBOC 

HERCBOC 

PATBOC 

CRC 

AIRBASE 

TAB 

AWACS 

LANCE 

HJ 


long. 

8  long. 


128 


I 


BRIDGE 

OEPOS 

PERSHING 

POL 

SASP 

ASP 

RESERVES 

TRAINS 

CLVBTRY 

VIII BTRY 

CORPBTRY 

CORPCP 

DIVCP 

SOC 

ATAF 


Optional  Plurals:  HAWKBTRY  =  HAWKBTRYS 

HERCBTRY  =  HERCBTRYS 
AIRBASE  =  AIRBASES 
SASP  =  SASPS 
ASP  =  ASPS 
RESERVE  =  RESERVES 
TRAIN  =  TRAINS 
CLVBTRY  =  CLVBTRYS 
VIII BTRY  =  VI I IBTRYS 
CORPCP  =  CORPCPS 

Optional  Abbreviations:  CRC  =  CRP 

CRC  =  GP 
CRC  =  GROUP 
CRC  =  MCC 
AIRBASE  =  AB 
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Example: 

Target  13  ATAF  is  at  HEX  7752352. 


•  Raid  NUMBER  has  NUMBER  wave  thru  NUMBER  corridor. 


Where  NUMBER  =  A  real  NUMBER 
Optional  Plurals:  raid  =  raids 

wave  =  waves 
corridor  =  corridors 


Example: 

Raid  23  has  3  wave  thru  2  corridor. 


•  Raid  NUMBER. 

Where  NUMBER  =  An  integer  NUMBER 
Optional  Plurals:  raid  =  raids 

Example: 

Raid  4. 


•  Red  theater  operations. 

Optional  Plurals:  theater  =  theaters 

Example: 

Red  theater  operations. 
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NUMBER  UNITTYPE  is  at  NUMBER  NUMBER  NUMBER  latitude  NUMBER  NUMBER 


NUMBER  longitude. 


Where  NUMBER  =  A  Real 
Where  UNITTYPE  = 


NUMBER  (Decimal  Degrees) 

HAWKBTRY 

HERCBTRY 

PATBTRY 

HAWKBOC 

HERCBOC 

PATBOC 

CRC 

AIRBASE 

TAB 

AWACS 

LANCE 

HJ 

BRIDGE 

DEPOS 

PERSHING 

POL 

SASP 

ASP 

RESERVES 

TRAINS 

CLVBTRY 

VIIIBTRY 

CORPBTRY 

CORPCP 

DIVCP 

SOC 

ATAF 
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Optional  Plurals:  HAWKBTRV  =  HAWKBTRYS 

HERCBTRY  =  HERCBTRYS 
AIRBASE  =  AIRBASES 
SASP  =  SASPS 
ASP  =  ASPS 
RESERVE  =  RESERVES 
TRAIN  =  TRAINS 
CLVBTRY  =  CLVBTRYS 
VIIIBTRY  =  VI I IBTRYS 
CORPCP  =  CORPCPS 
DIVCP  =  DIVCPS 
latitude  =  latitudes 
longitudes  =  longitudes 

Optional  Abbreviations:  CRC  =  CRP 

CRC  =  GP 
CRC  =  GROUP 
CRC  =  MCC 
AIRBASE  =  AB 
latitude  =  lat 
longitude  =  long 

Example: 

4  HAWKBOC  is  at  49.0  lat  11.9  long. 

15  AIRBASE  is  at  50.2  lat  8.0  long. 

14  HERCBTRY  is  at  48.3  lat  11.4  long. 

•  Label . 

Example: 

Label . 

MADEM  TEST  RUN 

Label . 

FINAL  TEST  RUN 
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Game  starts  at  NUMBER  hours  on  day  NUMBER. 

Where  NUMBER  =  An  integer  NUMBER 
Optional  Abbreviations:  HOURS  =  HRS 

Example: 

Game  starts  at  1100  hours  on  day  1. 


Corridor  NUMBER  limits  are  NUMBER  latitude  NUMBER  longitude 
NUMBER  latitude  NUMBER  longitude. 

Where  NUMBER  =  A  real  NUMBER  (Decimal  Degress) 

Optional  Plurals:  latitude  =  latitudes 

longitude  =  longitudes 

Optional  Abbreviations:  latitude  =  lat 

longitude  =  long 

Example: 

Corridor  1  limits  are  50.25  lat,  12.0  long,  50.33  lat,  11.64  long. 

Corridor  NUMBER  limits  are  NUMBER  NUMBER  NUMBER  latitude  NUMBER  NUMBER 
NUMBER  longitude 


Where  NUMBER  =  An  integer  NUMBER 

Optional  Plurals:  latitude  =  latitudes 

longitude  =  longitudes 


Optional  Abbreviations: 


latitude  =  lat 
longitude  =  long 


1 


Example: 

Corridor  4  limits  are  48.6  latitude  10.3  longitude. 


Corridor  NUMBER  depth  is  NUMBER  km  heading  NUMBER  degree  spread  angle 
NUMBER  degree. 

Where  NUMBER  =  An  integer  NUMBER 

Optional  Plurals:  degree  =  degrees 

Optional  Abbreviations:  degree  =  deg 

Example: 

Corridor  1  depth  is  70  km.  heading  245  deg.  spread  angle  60  deg. 


NUMBER  type  NUMBER  formation. 

Where  NUMBER  =  An  integer  NUMBER 

Optional  Plurals:  formation  =  formations 

Example: 

6  type  3  formations. 


NUMBER  UNITTYPE  is  at  hex  NUMBER. 


Where  NUMBER  =  An  integer  NUMBER 
Where  UNITTYPE  =  HAWKBTRY 

HERCBTRY 

PATBTRY 

HAWKBOC 
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HERCBOC 

PATBOC 

CRC 

AIRBASE 

TAB 

AWACS 

LANCE 

HJ 

BRIDGE 

DEPOS 

PERSHING 

POL 

SASP 

ASP 

RESERVES 

TRAINS 

CLVBTRY 

VIIIBTRY 

CORPBTRY 

CORPCP 

DIVCP 

SOC 

ATAF 

Optional  Plurals:  HAWKBTRY  =  HAWKBTRYS 

HERCBTRY  =  HERCBTRYS 
AIRBASE  =  AIRBASES 
SASP  =  SASPS 
ASP  =  ASPS 
RESERVE  =  RESERVES 
TRAIN  =  TRAINS 
CLVBTRY  =  CLVBTYS 
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VIII BTRY  =  VI I IBTRYS 
CORPCP  =  CORPCPS 
DIVCP  =  DIVCPS 

Optional  Abbreviations:  CRC  =  CRP 

CRC  =  GP 
CRC  =  GRDUP 
CRC  =  MCC 
AIRBASE  =  AB 

Example: 

10  HAWKBTRY  is  at  HEX  774225. 

12  PATBTRY  is  at  HEX  7777526. 

D.  MAIN  PROCESSOR  (RUNBIN) 

MADEM's  main  processor  (RUNBIN)  requires  two  primary  inputs:  a  set  of 
Run  Parameter  Cards  and  a  set  of  two  Hold  Files.  Each  of  these  required 
inputs  is  described  below. 

1 .  Run  Parameter  Cards 

The  Run  Parameter  Cards  control  the  main  processor  run.  There 
are  two  card  types.  The  first  is  mandatory.  The  second  is  optional.  The 
formats  of  these  cards  are  listed  below: 

CARD  1: 

PARM  1  -  Must  be  integer  '2'  for  RUNBIN 
PARM  2  -  Integer,  max  size  of  ISPACE.  (100000) 

PARM  3  -  Integer,  max  number  of  payers  on  either  side. 

PARM  4  -  Real,  max  CPU  time  of  volume  (in  seconds) 

PARM  5  -  Real,  max  game  time  of  this  volume. 

PARM  6  -  Integer,  max  number  of  events  for  this  volume. 
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The  second  set  of  options  are  all  optional.  Each  of  these 
PARMS  must  begin  in  column  11.  There  may  be  only  1  Parm 
Per  card,  with  as  many  cards  as  are  necessary.  It  is 
recommended  that  these  options  be  used  only  when  debugging 
PARMS: 

'DEBUG=0N'  -  Turns  on  full  debug  mode 

'DUMPIN'  -  Will  dump  ISPACE  at  end  of  volume. 

' REC0R=0FF '  -  Turn  off  system  recovery  routine 

EXAMPLE: 

2,100000,600,250,999999.20000 

DEBUG=0N 

DUMP=0N 

2.  Hold  Files 

The  two  Hold  Files  that  are  used  as  input  to  the  MADEM  main 
processor  are  created  by  the  preprocessor.  These  files  need  not  concern 
the  user  because  they  are  automatically  saved  and  accessed  by  the  current 
Job  Control  Language  (JCL).  This  will  allow  the  entire  data  base  to  be 
saved  for  restarts  of  the  main  processor. 

E.  POSTPROCESSOR  (HI  STB  IN) 

MAOEM's  postprocessor  (HISTBIN)  provides  printed  summaries  of  a 
variety  of  MADEM  events.  It  requires  two  inputs:  a  set  of  Run  Parameter 
Cards  and  History  Files.  Each  of  these  required  inputs  is  described  below. 

1 .  Run  Parameter  Cards 

The  Run  Parameter  Cards  control  the  main  processor  run.  There 
are  two  card  types.  The  formats  of  these  cards  are  listed  below: 

CARD  1: 

Up  to  70  character  description  of  the  scenario. 


Up  to  5  points  in  model  time  for  which  summary  statistics 
are  required.  If  the  first  time  is  negative  the  special 
option  to  list  attacks-on-acquisi tion  is  engaged. 

EXAMPLE: 

CONVENTIONAL  1978  AAA  LEVEL  2  PK 
390001,  999999999.,  999999999.,  999999999.,  999999999. 

Note  that  the  last  four  parameters  on  card  2  of  the  example  are 
essentially  dummy  parameters.  Since  there  are  no  events  after  time  390001, 
only  one  history  "snapshot"  will  be  taken. 

2.  History  Files 

The  history  files  that  are  used  as  input  to  the  MADEM  postpro¬ 
cessor  are  created  by  the  preprocessor  and  the  main  processor.  These  files 
need  not  concern  the  user  because  they  are  automatically  saved  and  accessed 
by  the  current  job  control  cards  (JCL).  These  files  contain  event  informa¬ 
tion  to  be  extracted  and  organized  in  a  meaningful  format  to  analyze  the 
model  run. 


SECTION  VI 
EXAMPLE  CASE 


A.  INTRODUCTION 


The  purpose  of  this  chapter  is  to  describe  all  of  the  required  inputs 
and  resulting  outputs  associated  with  a  simple  MADEM  scenario.  The 
scenario  used  in  this  example  case  is  a  variant  of  the  basic  test  data  set 
which  was  used  to  develop  and  debug  the  current  version  of  MADEM.  Section 
B  describes  the  basic  elements  of  the  scenario  while  sections  C  and  D 
describe  the  required  inputs  and  resulting  outputs. 

B.  SCcNARI0  SPECIFICATION 

1 .  General  Description 

The  scenario  used  in  this  example  represents  a  considerable 
simplification  of  typical  MADEM  analysis  run.  While  the  overall  configura¬ 
tion  of  units  is  realistic,  the  total  unit  density  in  the  simulate"  battle 
area  is  much  lower  than  the  actual  unit  density  in  the  2  ard  4  ATAF  area 
represented  in  the  scenario.  This  lower  unit  density  was  used  to  simplify 
the  scenario  for  explanatory  purposes  and  to  reduce  the  run  time  and 

storage  requirements  for  testing. 

2 

2.  Unit  Locations  and  C  Relationships 

Figure  VI-1  shows  the  locations  of  all  units  in  the  scenario  and 
their  command/control  relationships.  Figure  Vi-2  shows  the  LAT/LONG  over¬ 
lay  used  to  input  unit  locations  in  the  user  input  language  file.  The  Red 
theater  commander,  located  to  the  right  of  the  border  line,  commands  four 
Red  airbases.  Each  of  the  two  combat  reporting  centers  on  the  blue  side 
commands  two  airbases,  and  two  battalion  operations  centers.  Each  HAWK  BOC 
in  turn  commands  three  HAWK  batteries,  while  each  Ni ke-Hercules  BOC  com¬ 
mands  two  Ni ke-Hercul es  batteries.  In  addition,  a  number  of  passive  tar¬ 
gets  have  been  included  on  the  Blue  side  to  draw  additional  red  attacks. 

O 

It  should  be  noted  that  these  passive  targets  are  not  connected  to  the 
tree  and  do  not  play  an  active  role  in  the  battle. 


139 


3. 


Blue  Air  Defense  Specification 

The  Blue  side's  defensive  assets  include  the  aircraft  on  the  four 
blue  airbases  and  the  ten  SAM  batteries.  Each  of  the  Blue  airbases  has 
been  assigned  12  interceptor  aircraft.  These  interceptors  must  fly  in 
flights  of  2  to  4  aircraft.  Each  HAWK  battery  has  been  supplied  with  18 
conventional  missiles.  Ni ke-Hercules  batteries  have  been  supplied  with  14 
conventional  missiles  each.  All  blue  SAM  batteries  will  be  resupplied  with 
2  missiles  every  6  hours.  Missile  fire  ranges  for  all  batteries  are 
indicated  in  Figure  VI-3.  Further  details  of  the  Blue  defenses  can  be 
found  in  the  sample  data  base  file  in  figure  VI-6  in  section  C.  1  of  this 
chapter. 

4.  Red  Attack  Specification 

The  aircraft  on  the  red  airbases  constitute  the  Red  side's  pri¬ 
mary  offensive  assets.  Assignments  of  aircraft  to  the  four  red  airbases 
are  as  fol lows: 


AIRBASE  BOMBERS 

FIGHTER/BOMBERS 

FIGHTERS 

19 

34 

15 

11 

20 

32 

24 

9 

21 

32 

23 

17 

22 

36 

24 

16 

In  contrast  to  the  simple 

f  1  ight 

assignment  used  on  the 

Blue  side,  a 

complex  assignment  of 

aircraft  to 

flight  and  formation  types  has  been 

on  the  Red  side.  Specified 

f  1  ight 

assignments  for  the  Red 

side  include 

fol lowing: 

FLIGHT  TYPE 

NUMBER  O'7  AIRCRAFT 

6 

2  -  4  FIGHTERS 

5 

2-6  FIGHTERS 

4 

2  -  4  FIGHTER/BOMBERS 

3 

3  -  6  FIGHTER/BOMBERS 

2 

8  -  12  BOMBERS 

1 

4-16  BOMBERS 
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It  should  be  noted  that  each  of  the  above  flight  types  carries  a  different 
user  defined  weapons  package. 

These  Red  flights  must  be  further  grouped  into  formation  types 
for  assignment  to  Blue  targets.  Specified  formation  types  are  as  follows: 

FORMATION  TYPE  FLIGHT  TYPES  IN  THE  FORMATION 

3  2-4  FIGHTER/BOMBERS  -  Type  4 

2  3-6  FIGHTER/BOMBERS  -  Type  3 

2  -  6  FIGHTERS  -  Type  5 

8-12  BOMBERS  -  Type  2 

1  4-16  BOMBERS  -  Type  1 

2-4  FIGHTERS  -  Type  6 

In  this  scenario  these  formation  types  have  been  used  to  specify  a  two  wave 
raid  on  the  Blue  side.  The  specification  parameters  for  each  wave  in  the 
raid  are  discussed  below.  The  Red  attack  plans,  which  the  model  generates 
from  these  specifications,  are  discussed  in  section  D.l  of  this  chapter. 

a.  First  Wave  -  Corridor  Clearing 

The  first  wave  attack  specifications  for  this  scenario  are 
illustrated  in  Figure  VI-4.  The  purpose  of  this  wave  is  to  clear  the 
attack  corridors  of  SAM  batteries.  The  specifications  for  this  wave  are 
input  in  the  user  input  language  file  listed  in  section  C.  1  of  this 
chapter.  They  specify  two  attack  corridors  with  40  km  buffer  zones.  Up  to 
6  type  3  formations  may  be  assigned  by  the  red  theater  planner  to  attack 
HAWK  batteries  within  90  km  of  the  corridor  exits.  Up  to  2  type  1  forma¬ 
tions  may  be  assigned  by  the  red  theater  planner  to  attack  Ni ke-Hercules 
batteries  within  190  km  of  the  corridor  exits.  It  should  be  noted  that 
these  are  the  maximum  allocations  input  by  the  user.  They  act  as  con¬ 
straints  upon  the  actions  of  the  model  which  may  assign  fewer  formations 
than  specified  due  to  lack  of  aircraft. 

b.  Second  Wave  -  Deep  Penetration 

Figure  VI-5  illustrates  the  second  wave  attack  specifica¬ 
tions  for  this  scenario.  The  same  two  corridors  have  been  specified  for 
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use  in  this  wave  as  in  the  first  wave.  Corridors  should  have  been  cleared 
of  SAM  batteries  in  the  first  wave.  The  primary  purpose  of  this  wave  is  to 
penetrate  deep  into  Blue  air-space  to  attack  airbases  and  passive  targets. 
If  further  corridor  clearing  is  required  up  to  4  type  3  formations  may  be 
assigned  to  attack  HAWK  batteries  within  150  km  of  the  corridor  exit. 
Airbases  may  be  attacked  with  up  to  4  type  2  formations.  The  two  types  of 
passive  targets  (SASPS  and  HJ's)  may  be  attacked  with  up  to  2  type  1  plus  2 
type  2  and  2  type  1  formations  respectively. 

C.  REQUIRED  INPUTS 

A  MADEM  simulation  is  run  in  three  stages:  the  preprocessor ,  the  main 
processor,  and  the  post  processor.  The  main  processor  can  run  in  several 
volumes,  generally  between  six  and  twelve  volumes.  MADEM  runs  at  the  AFWL 
computer  center  on  either  of  the  two  CDC  Cyber  176  computers  (MFY  or  MFX). 
MADEM  cannot  run  the  Cyber  166,  referred  to  as  MFB. 

This  section  includes  all  the  required  inputs  to  run  an  example  MADEM 
simulation,  including  Job  Control  Language  (JCL)  to  run  all  three  stages  of 
MADEM  as  well  as  the  Data  Base  File  and  User  Oriented  Input  Language  File 
(UOIL)  necessary  to  run  the  preprocessor.  In  the  sample  JCL  streams,  the 
second  card,  the  account  card,  will  have  to  be  altered  to  provide  a  valid 
account  number  and  password.  See  Appendix  D  for  explanations  of  the  first 
two  JCL  cards  and  the  end-of-record  and  end-of- i nformati on  cards. 

1 .  Preprocessor  Input 

To  run  the  preprocessor  for  our  example  case  the  following  perm¬ 
anent  files  must  reside  on  the  AFWL  system: 

MADEMINITBIN  -  Executable  preprocessor  program 

DATFILEEXAMPLE  -  Example  data  base. 

UOILEXAMPLE  -  Example  User  Input  Language  File. 

See  figures  VI-6  and  VI-7  respectively,  for  the  sample  Data  Base  File  and 
the  sample  User  Oriented  Input  Language  File. 


147 


OATFILE  TEST  CASE  1  —  CONVENTIONAL  4  DEC  1979 
6026 

180,1  ,3,30,15.75. ,0. ,10. ,0. ,0. 

1.1 .2.5.3.1000000.90. . 150000. .9.11.0. .180000. .15. 

0. ,0. ,14,0,0,21600,2,0,0,0,0 

175.1.12.30.15.75. . 0. .10. .0. .0. 

1 . 1 .2.5.3.1000000.60. . 90000. .0.11.0. .100000. .15. 

0  .0. ,20,0,0,21600,2,0,0,0,0 

70.1,3,30,15,75. ,0. ,10. ,0. ,0. 

’ . 1 .2,5,3,1000000,45. ,50000. ,0,11 ,0. ,100000.  ,15. 

0. .0. ,18,0,0,21600,2,0,0,0,0 

160.1 .3.30.15.75. . 37. .10. .0. .0. 

1  ,1  ,2,5,3,100000,90.  ,150000. ,1,8,5. ,5. ,5. 

0. ,0. ,0,0, 0,0, 0,0, 0,0,0 

155.1.15.30.15.75. . 37.  ,30.  ,0.  ,0. 

1.1.2.5.3.1000000.60. . 90000. .1.8.5. .5. .5. 

0. ,0. ,0,0, 0,0, 0,0, 0,0,0 

150.1.3.30.15.75. . 37. .10. .0. .0. 

1.1.2.5.3.1000000.45. . 50000. .1.8.5. .5. .5. 

0. ,0. ,0,0, 0,0, 0,0, 0,0,0 

7,6006 

220,50000. 

130.200000. 

400,60000. 

160.200000. 

150,200000. 

130,300000. 

170,100000. 

2,6004 

3,6 

1 

2 

3 

4 

5 

6 

4,3 

1 

2 

3 

4,6003 

460.420.280. . 15000. .100. .1500. 

1. . 60000. .10. .800000. .200. 

440.435. . 290. .17000. .50. .1500. 

1 . . 60000. .4. .800000. .200. 

420. 480..  320.. 20000. .50. .1500. 

1 . . 60000. .2. .800000. .200. 

Figure  VI-6.  Sample  Data  Base  File 
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401  ,525.  ,350. ,20000. ,150. ,1500. 

1. . 60000. .3. .800000. .200. 

4,6005 

4.10000. . 10000. .10000. 

8.5000. . 5000. .5000. 

2.500. . 500. .5000. 

1  ,5000. ,500. ,5000. 

7,6002 

7,401 ,4,2,2,4,350,500.  ,3 

2,2,1 

4. 2. 2. 2 

4. 4. 4. 3 

6 ^420  ^4 ,2 , 1 ,3,320.  ,500.  ,2 

4. 3. 3.1 

4. 4. 4. 2 

5  ^420  ^6 , 2,1,2, 320. ,500.  ,2 

4.4.4. 1 

4. 2. 2. 2 

4 1 440^4, 2, 1  ,1,290. ,500. ,3 

4, 2, 2, 2 

3. 4. 4. 4 
3, 4, 4, 6 

3.440.6.3.1.2.290. . 500.  ,3 
4,3,3, 1 

3. 8. 8. 4 

3  2  2  6 

2 ] 460 ] 1 2 ,8 ,2 , 3,280. ,500. ,1 

3. 6. 6. 5 

1 .460.16.4.2.3.280. . 500.  ,2 

3.4. 4. 5 

3. 2. 2. 6 
4,6001 
4,350.  ,1 
7 

290.  ,1 

4 

2.280.  ,3 
3 

5 

2 

1 .280.  ,2 
1 

6 

1  ,6007 

1 .. 005.0.  ,.2 
8,6008 

19,3 

460,34,0 


440,15,0 


Figure  VI-6.  Sample  Data  Base  File  (Continued) 
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420,11,0 

20.3 

460,32,0 
440,24,0 
420,9,0 
21  ,3 

460,32,0 

440,23,0 

420,17,0 

22.3 
60,36,0 

440,24,0 

420,16,0 

15.1 

401,12,4 

16.1 

401,12,4 

7,1 

401,12,4 

18,1 

401,12,4 
1 ,6101 

.25,. 24,. 26,. 25,. 02,. 26,. 25,. 02,. 0,.0 
26,6102 


o 

.0 

.0 

■  0 

.0013. 

.0 

.0403, 

.  1624, 

.  0 

,.0 

,.o 

o 

.0 

.0 

.0 

.0013, 

•  0 

.0403, 

•  0 

.0 

,.o 

,.0 

o 

.0 

.3687, 

.9567, 

.0 

.0988, 

.0 

.0 

.  0 

,.o 

,•0 

o 

.0 

.3014, 

•  0 

.0 

.0 

•  0 

■  0 

.0 

,.o 

,.o 

o 

.0 

.3014, 

.0 

.0 

•  0 

•  0 

.0 

.0 

,.o 

,.o 

o 

.0287, 

.0316, 

■0 

.0322, 

■  0 

•  0 

•  o 

.0 

,.0 

,.0 

o 

.0305, 

.0 

.0 

.0 

.0 

•0 

•  o 

.0 

,.o 

,.o 

o 

.0646, 

.0 

•  0 

■  0 

.  0 

•  0 

.0 

.  0 

,.o 

,.o 

o 

. 1456, 

.0 

.0 

■  0 

■  0 

■0 

•  o 

.0 

,.0 

,.0 

o 

.5236, 

.0 

.3638, 

■  0 

.0 

•  0 

•  o 

.  0 

,.0 

,.o 

o 

.0 

.0 

■  0 

.0626, 

.0 

•  0 

•  0 

.0 

,.o 

,.o 

2435, 

.0800, 

.0 

.0 

•  0 

.1663, 

.2493, 

•  0 

.0 

,.o 

,.0 

4986, 

.0 

.0 

.0 

•  0 

.0 

.2500, 

.0 

.0 

,.o 

,.o 

4950, 

.2240, 

.0 

.0 

•  0 

.0 

.  2430, 

■  0 

.0 

,.0 

,.0 

0 

.0020, 

.0 

.0044, 

•  0 

•  0 

•  0 

.0 

.0 

,.0 

,.o 

0 

■  0 

.1840, 

.0 

.0 

.  o 

•  0 

•  0 

.0 

,.0 

,.o 

0 

■  0 

. 1840, 

.0 

.0 

.0 

•  0 

.  o 

.0 

,.o 

,.o 

0 

.0 

.1840, 

•  0 

•  0 

•  0 

.0 

.0 

.  0 

,.0 

,.0 

0 

.0 

■  o 

.0 

.7664, 

•  0 

•  0 

-0 

.  0 

..0 

,.0 

0 

•  0 

.1840, 

.0 

.0 

■  o 

.0 

.  o 

.  0 

,.0 

,.0 

0 

.0 

.0 

.0 

. 2250, 

.0 

.  5030, 

.  o 

.  0 

,.o 

,.0 

o 

•  0 

.0700, 

•  0 

.0 

.0 

•  0 

.  o 

.0 

,.o 

,.0 

0 

.0158, 

■  0 

.0593, 

.0 

.0 

•  0 

.0 

.  n 

,.o 

,.o 

0 

.0306, 

.0 

•  0 

.0 

.0 

•  0 

.  o 

.0 

,.o 

,.0 

0 

■  0 

•  0 

.0 

•  0 

.0 

•  o 

.  o 

.  0 

,.o 

,.o 

o 

•  0 

.0  , 

.0 

.0 

.0 

.0 

.  o 

.  0 

,.o 

,.0 

Figure  VI-6.  Sample  Data  Base  File  (Continued) 
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if 

l 

i 

I 

i 

'  9,6103 

.447,  -1.01 E- 5 

i  .536,  -4.0685E-6 

.310,  -1.6636E-6 

|  .00,  0.0 

i  .96,  -1.004787E-6 

j  .80,  0.0 

;  .oo,  o.o 

j  .00,  0.0 

.90,  0.0 

i  10,6201 

:  .68,0. ,0. ,0. ,.84,1 . ,.68,  .68 

|  1. ,.68,0. ,0. ,0. ,0. ,.67,0. 

j  0.  ,0.  ,.68,0. ,.68,0.  ,0.  ,1 . 

i  .68,0. ,0. ,1. ,0. ,0. ,.68,0. 

0. ,0. ,0. ,0. ,0. ,0. ,.84,0. 

0.  ,0. ,1. ,1.  .68,0.  ,1.  ,1. 

0. ,.67,0.  ,0.  ,0.  ,0. ,.68,0. 

0.  ,0. ,0. ,.84,1 . ,0. ,.68,0. 

0.  ,0.  ,0. ,0.  ,0.  ,0.  ,0. ,0. 
i  0.  ,0.  ,0.  ,0.  ,0.  ,0.  ,0.  ,0. 


Figure  VI-6.  Sample  Data  Base  File  (Continued) 
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LABEL. 

MADEM  TEST  RUN  a  MAY  1977 

LABEL. 

FINAL  TEST  RUN  WITH  INPUT  AND  PLAN 
BLUE. 

99  ATAF  COMMANDS  1  CRC. 

1  CRC  IS  AT  49.7  LAT  10.0  LONG. 

99  ATAF  COMMANDS  2  CRC. 

2  CRC  IS  AT  49.2  LAT  9.7  LONG. 

1  CRC  COMMANDS  3  HAWKBOC. 

3  HAWKBOC  IS  AT  49.5  LAT  11.1  LONG. 

1  CRC  COMMANOS  4  HAWKBOC. 

4  HAWKBOC  IS  AT  49.0  LAT  11.9  LONG. 

2  CRC  COMMANDS  5  HERCBOC. 

5  HERCBOC  IS  AT  49.8  LAT  9.1  LONG. 

2  CRC  COMMANDS  6  HERCBOC. 

6  HERCBOC  IS  AT  48.6  LAT  10.3  LONG. 

3  HAWKBOC  COMMANDS  7  HAWKBTRY. 

7  HAWKBTRY  IS  AT  50.1  LAT  10.8  LONG. 

3  HAWKBOC  COMMANDS  8  HAWKBTRY. 

8  HAWKBTRY  IS  AT  49.9  LAT  11.5  LONG. 

3  HAWKBOC  COMMANDS  28  HAWKBTRY. 

28  HAWKBTRY  IS  AT  49.58  LAT  12.02  LONG. 

4  HAWKBOC  COMMANDS  9  HAWKBTRY. 

9  HAWKBTRY  IS  AT  49.3  LAT  12.3  LONG. 

HAWKBOC  COMMANDS  10  HAWKBTRY. 

10  HAWKBTRY  IS  AT  49.0  LAT  12.1  LONG. 

4  HAWKBOC  COMMANDS  29  HAWKBTRY. 

29  HAWKBTRY  IS  AT  49.1  LAT  12.7  LONG. 

5  HERCBOC  COMMANDS  11  HERCBTRY. 

11  HERCBTRY  IS  AT  50.1  LAT  9.7  LONG. 

5  HERCBOC  COMMANDS  12  HERCBTRY. 

12  HERCBTRY  IS  AT  49.4  LAT  11.2  LONG. 

6  HERCBOC  COMMANDS  13  HERCBTRY. 

13  HERCBTRY  IS  AT  49.1  LAT  10.8  LONG. 

6  HERCBOC  COMM'HDS  14  HERCBTRY. 

14  HERCBTRY  IS  AT  48.3  LAT  11.4  LONG. 

1  CRC  COMMANDS  15  AIRBASE. 

15  AIRBASE  IS  AT  50.2  LAT  8.0  LONG. 

1  CRC  COMMANOS  16  AIRBASE. 

16  AIRBASE  IS  AT  49.4  LAT  8.4  LONG. 

2  CRC  COMMANDS  17  AIRBASE. 

17  AIRBASE  IS  AT  48.8  LAT  8.2  LONG. 

2  CRC  COMMANDS  18  AIRBASE. 

18  AIRBASE  IS  AT  48.2  LAT  8.8  LONG. 

TARGET,  23  SASP  IS  AT  50.0  LAT,  8.4  LONG. 

TARGET,  24  SASP  IS  AT  49.2  LAT,  7.8  LONG. 

TARGET,  25  SASP  IS  AT  49.1  LAT,  10.2  LONG. 

Figure  VI-7.  User  Oriented  Input  Language  File 
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TARGET,  26  SASP  IS  AT  48.0  LAT,  8.6  LONG. 

TARGET,  27  HJ  IS  AT  48.9  LAT,  10.8  LONG. 

RED. 

30  WP  COMMANDS  19  AIRBASE. 

30  WP  IS  AT  51.5  LAT,  13.8  LONG. 

19  AIRBASE  IS  AT  51.4  LAT,  11.4  LONG. 

30  WP  COMMANDS  20  AIRBASE. 

20  AIRBASE  IS  AT  51.1  LAT,  12.4  LONG. 

30  WP  COMMANDS  21  AIRBASE. 

21  AIRBASE  IS  AT  50.35  LAT  14.08  LONG. 

30  WP  COMMANOS  22  AIRBASE. 

22  AIRBASE  IS  AT  50.1  LAT,  14.2  LONG. 

RED  THEATER  OPERATIONS. 

RAID  1 

CORRIDOR  1  LIMITS  ARE  50.25  LAT,  12.0  LONG,  50.33  LAT,  11.64  LONG 
CORRIDOR  1  DEPTH  IS  70  KM,  HEADING  245  DEG,  SPREAD  ANGLE  60  DEG. 
BUFFER  ZONE  WIDTH  IS  40  KM. 

CORRIDOR  2  LIMITS  ARE  49.5  LAT,  12.9  LONG,  49.63  LAT,  12.72  LONG. 
CORRIDOR  2  DEPTH  IS  60  KM,  HEADING  230  DEG,  SPREAD  ANGLE  60  DEG. 
BUFFER  ZONE  WIDTH  IS  40  KM. 

WAVE  1  START  TIME  IS  0630  HRS  DAY  1  FOR  5  MIN. 

TARGET  TYPE  HAWKBTRYS ,  1  FORMATION  90,0  KM  RANGE  LIMITS. 

6  TYPE  3  FORMATIONS. 

TARGET  TYPE  HERCBTRYS ,  1  FORMATION,  190,20  KM  RANGE  LIMITS. 

2  TYPE  1  FORMATIONS. 

WAVE  2  START  TIME  IS  0645  HRS  OAY  1  FOR  10  MIN. 

TARGET  TYPE  HAWKBTRYS,  1  FORMATION,  150,0  KM  RANGE  LIMITS. 

TYPE  3  FORMATIONS. 

TARGET  TYPE  AIRBASES,  1  FORMATION ,400 , 1 50  KM  RANGE  LIMITS. 

4  TYPE  2  FORMATIONS. 

TARGET  TYPE  SASPS,  2  FORMATIONS,  440,  60  KM  RANGE  LIMITS. 

2  TYPE  1  FORMATIONS. 

2  TYPE  2  FORMATIONS. 

TARGET  TYPE  HJ ,  1  FORMATION,  200,50  KM  RANGE  LIMITS. 

2  TYPE  1  FORMATIONS. 


Figure  VI-7.  User  Oriented  Input  Language  File  (Continue 


a.  Preprocessor  Job  Control  Language 

The  preprocessor  job  control  stream  in  figure  V I  -  8  will 
execute  the  MADEM  example  preprocessor.  The  COMMENT  cards  are  for  your 
information  only,  and  may  be  omitted.  The  three  REQUEST  cards  allocate 
permanent  file  space  for  the  History  File  (TAPE4)  and  the  two  Hold  Files. 
The  ATTACH  cards  access  the  necessary  permanent  files  listed  above.  After 
executing  INITBIN,  the  History  File  and  the  two  Hold  Files  are  saved  as 
permanent  files,  and  the  planner  output  in  TAPE14  is  sent  to  the  printer. 
Everything  after  the  EXIT  card  is  only  executed  if  the  system  abnormally 
aborts  the  job  stream.  In  this  case  debug  information  will  be  sent  to  the 


pri nter. 


b.  Preprocessor  Run  Parameters 


The  next  to  last  card  in  the  job  stream  is  the  Run  Para¬ 
meters  card.  In  includes  six  parameters: 

(1 )  a  one  for  INITBIN. 

(2)  size  of  ispace  (50,000) 

(3)  maximum  number  of  players  on.  either  side  (600) 

(4)  dummy  val ue  (25) 

(5)  dummy  value  (999999) 

(6)  dummy  value  ( 1 ) 

2.  Main  Processor  Inputs 

A  full  production  run  is  generally  run  in  volumes,  but  may  be 
accomplished  in  one  run.  If  it  is  run  in  volumes,  the  simulation's  memory, 
contained  in  an  array  called  ISPACE,  is  saved  on  Hold  Files  to  be  used  in 
starting  the  next  volumes.  The  length  of  a  volume  is  controlled  by  the 
fourth,  fifth,  and  sixth  run  parameters  (see  Section  (b)  below).  A  large 
production  run  will  use  about  2,000  (3,720  octal)  CP  seconds  and  about  120 
(170  octal)  I/O  seconds,  thus  running  at  priority  P10.  Volumes  of  about 
30,000  events  each  will  use  about  200  (310  octal)  CP  seconds  and  10  1/0 
seconds,  thus  running  at  priority  P60.  A  large  run  could  take  between 
eight  and  twelve  of  these  volumes.  For  an  explanation  of  these  job  card 
parameters,  see  Appendix  0  or  an  AFWL  SVSBULL. 


154 


76 , T30 , 1050 , P66 , EC1 50.  MADEM  PREPROCESSOR  (EXAMPLE) 

MADEM, ********-ZZZ ,8DM, 703-821 -4223.  B  MACALEER 


*************************************** 
*  * 


*  MADEM  PREPROCESSOR  (EXAMPLE): 

*  PLANS  RED  RAID 

*  READS  DATFILE,  UOIL  INPUT 

*  GENERATES  ISPACE 

*  SAVES  ISPACE  ON  HOLD  FILES 

* 

*  FILES:  * 

*  TAPE4  -  HISTORY  FILE  * 

*  TAPE7  -  UOIL  INPUT  * 

*  TAPE8  -  DATFILE  INPUT  * 

*  TAPE10  -  FIRST  HOLD  FILE  * 

*  TAPE11  -  SECOND  HOLD  FILE  * 

*  TAPE14  -  PRINTED  PLANNER  OUTPUT  * 

*  * 

*************************************** 


MADEM, ST  1 
ACCOUNT 
COMMENT. 

COMMENT. 

COMMENT. 

COMMENT. 

COMMENT. 

COMMENT. 

COMMENT. 

COMMENT. 

COMMENT. 

COMMENT. 

COMMENT. 

COMMENT . 

COMMENT. 

COMMENT. 

COMMENT. 

COMMENT. 

COMMENT. 

REQUEST , TAPE4 , *PF . 

REQUEST, TAPE10,*PF. 

REQUEST, TAPE11 ,*PF. 

ATTACH,TAPE7 ,UQ I  LEX AMPLE , ID-WDNA14V6. 

ATTACH , TAPES , DATFI LEEXAMPLE , ID=WDNA1 4V6 . 

ATTACH, INITBIN.MADEMINITBIN, ID=W0NA!4V6. 

LDStT ,PRESET=ZERO. 

LOAD , INITBIN. 

EXECUTE. 

REWIND,  TAPE4, TAPE! 0, TAPE! 1 .TAPE14. 

COMMENT  *************************************** 
COMMENT.  *  SAVE  HISTORY  FILE  AND  HOLD  FILES  * 
COMMENT.  *************************************** 
CATALOG , TAPE4, EXAMPLEHISTPLAN , ID=WDNA14V6 , RP=999. 
CATALOG, TAPE  1 0 , EXAMPLEPLAN1 , ID=WDNA14V6 , RP=999. 
CATALOG  JAPE  1 1 , EXAMPLEPLAN2 , ID=WDNA1 4V6 , RP=999 . 
COMMENT.  *************************************** 
COMMENT.  *  GET  PRINTED  OUTPUT  * 

COMMENT.  *************************************** 
C0PYBFJAPE14,  OUTPUT 
COMMENT. 


COMMENT. 

COMMENT. 

COMMENT. 

COMMENT. 

COMMENT. 

COMMENT. 

COMMENT. 

COMMENT. 

COMMENT. 

EXIT. 


*************************************** 

*  FIRST  INPUT  CARD  IS  MANDATORY  AND  * 
HOLDS  6  PARAMETERS: 

2.  MUST  BE  1  FOR  PREPROCESSOR 

2.  SIZE  OF  ISPACE  (50000) 

3.  MAX  NO.  PLAYERS  ON  ONE  SIDE 

4.  DUMMY  VALUE  (25) 

5.  DUMMY  VALUE  (999999) 

6.  DUMMY  VALUE  (1) 
*************************************** 


Figure  VI-8.  Preprocessor  Job  Control  Language 
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COMMENT  It***********.*.**.*.*****.**.*******.*.*******.* 
COMMENT.  *  WE  HAVE  BOMBED,  GET  OUTPUT  ANYWAY  * 
COMMENT  *************************************** 
DMP, 100,7200. 

DMPECS, 0,1000 
REWIND, TAPE14.TAPE6. 

C0PYBF.TAPE14, OUTPUT. 

C0PYBF.TAPE6, OUTPUT. 

&  EOR 

1 ,50000,600,25,999999,1 
#  EOI 


! 


Figure  VI-8.  Preprocessor  Job  Control  Language  (Continued) 
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To  run  the  main  processor  for  our  example  case,  the  following 
permanent  files  must  reside  on  the  AFWL  system: 

MADEMRUNBIN  -  Executable  main  processor  program 

EXAMPLEPLAN1  -  First  Hold  File,  created  by  the  pre¬ 

processor 

EXAMPLEPLAN2  -  Second  Hold  File,  created  by  the  pre¬ 
processor 


The  last  two  files  should  be  taken  care  of  by  the  preprocessor,  and  norm¬ 
ally  should  not  concern  the  user. 

a.  Main  Processor  Job  Control  Language 

The  production  run  job  control  stream  in  figure  VI-9  will 
execute  the  MADEM  main  processor.  The  COMMENT  cards  are  for  your  informa¬ 
tion  only  and  may  be  omitted.  The  three  REQUEST  cards  allocate  permanent 
file  space  for  the  History  File  (TAPE4)  and  the  Hold  Files.  The  ATTACH 
cards  access  the  permanent  files  listed  above.  After  executing  RUNBIN,  the 
History  File  and  Hold  Files  are  saved  permanently.  The  event  trace 
messages  in  TAPE6  are  sent  to  the  printer.  If  more  than  one  raid  was 
called  for,  TAPE14  will  have  plan  output  to  be  sent  to  the  printer  as  well. 
Everything  after  the  EXIT  card  is  only  executed  if  the  system  abnormally 
aborts  the  job  stream.  In  this  case  debug  information  will  be  sent  to  the 
pri nter. 

If  the  main  processor  is  run  in  more  than  one  volume,  use  the 
volume  cards  listed  in  figure  VI-10.  There  are  eight  sets  of  volume  cards 
listed,  the  first  of  which  is  already  in  the  JCL.  To  run  volume  2,  just 
replace  the  volume  1  cards  in  the  job  stream  with  the  respective  volume  2 
cards.  This  process  can  be  continued  for  as  many  volumes  as  is  necessary 
to  complete  the  run.  Just  continue  to  replace  volume  cards  with  the  next 
volume  cards. 

b.  Main  Processor  Run  Parameters 

The  next  to  the  last  card  in  the  job  control  stream  is  the 
Run  Parameters  Card.  It  includes  six  parameters: 

(1)  a  two  for  RUNBIN 


MADEM , ST1 76 , T300 ,10100, P60 , EC305.  MADEM  PRODUCTION  RUN  (EXAMPLE) 

ACCOUNT  MADEM, ******- ZZZ , BOM, 703-821-4223.  B  MACALEER 

COMMENT  *************************************** 

COMMENT.  *  * 

COMMENT.  *  MADEM  PRODUCTION  RUN  (EXAMPLE)  * 

COMMENT.  *  * 

COMMENT.  *  FILES:  * 

COMMENT.  *  TAPE4  -  HISTORY  FILE  * 

COMMENT.  *  TAPE6  -  PRINTED  EVENT  TRACE  * 

COMMENT.  *  TAPE  1 0  -  FIRST  HOLD  FILE  * 

COMMENT.  *  TAPE  1 1  -  SECOND  HOLD  FILE  * 

COMMENT.  *  TAPE  14  -  PLAN  OUTPUT  (IF  ANY)  * 

COMMENT.  *  * 

COMMENT  *************************************** 

REQUEST, TAPE4,*PF. 

REQUEST, TAPE10,*PF. 

REQUEST, TAPE! 1 ,*PF. 

COMMENT  *************************************** 

COMMENT.  *  VOLUME  1,  RUN  TYPE  EXAMPLE  * 

COMMENT  *************************************** 

ATTACH, TAPE15.EXAMPLEPLAN1 , I0=WDNA14V6. 

ATTACH , TAPE  1 6 , EXAMPLEPLAN2 , 1 D=WDNA 1 4V6 . 

ATTACH ,RUNBIN,MADEMRUNBIN,ID=WDNA14V6. 

LOSET,PRESET=ZERO. 

LOAD , RUNBIN. 

EXECUTE, ,PL=20000. 

REWIND, TAPE4, TAPES, TAPE10 ,TAPE1 1 ,TAPE14. 

COMMENT  *************************************** 

COMMENT.  *  SAVE  HISTORY  FILE  AND  HOLD  FILES  * 

COMMENT  *************************************** 

CATALOG , TAPE4 , EXAMPLEHISTV0L1 , ID=WDNA14V6 , RP=399. 

CATALOG , TAPE1 0 , EXAMPLEV0L1 A , ID=WDNA14V6 , RP=999. 

CATALOG , TAPE! 1 , EXAMPLEV0L1B , ID=WDNA1 4V6 , RP=999. 

COMMENT  *************************************** 

COMMENT.  *  GET  PRINTED  OUTPUT  * 

COMMENT  *************************************** 

C0PYBF,TAPE14, OUTPUT. 

C0PYBF.TAPE6, OUTPUT. 

COMMENT.  *************************************** 

COMMENT.  *  FIRST  INPUT  CARD  IS  MANDATORY  AND  * 

COMMENT.  *  HOLDS  6  PARAMETERS:  * 


COMMENT. 

* 

1 . 

MUST 

BE 

2  FOR  RUNBIN 

* 

COMMENT. 

* 

2. 

SIZE 

:  OF 

ISPACE  (100000) 

* 

COMMENT. 

* 

3. 

MAX 

NO. 

PLAYERS  ON  ONE  SIDE 

* 

COMMENT. 

* 

4. 

MAX 

CPU 

TIME  OF  THIS  VOLUME 

* 

COMMENT. 

* 

5. 

MAX 

GAME 

:  TIME  OF  THIS  VOLUME 

* 

COMMENT. 

* 

6. 

MAX 

NO  OF  EVENTS  FOR  THIS  VOL 

* 

COMMENT  *************************************** 

EXIT. 

Figure  VI-9.  Main  Processor  Job  Control  Language 
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COMMENT  *************************************** 
COMMENT.  *  WE  HAVE  BOMBED,  GET  OUTPUT  ANYWAY  * 
COMMENT  *************************************** 
OMP, 100,7200. 

DMPECS, 0,1000. 

REWIND, TAPE14.TAPE6. 

C0PYBF,TAPE14, OUTPUT. 

C0PYBF.TAPE6, OUTPUT. 

&  EOR 

2 , 1 00000 , 600,235 , 00000 , 20000 
#  EOI 


Figure  VI-9.  Main  Processor  Job  Control  Language  [Continued) 
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COMMENT  *************************************** 
COMMENT.  *  VOLUME  1,  RUN  TYPE  EXAMPLE  * 

COMMENT  *************************************** 
ATTACH , TAPE  1 5 , EXAMPLEPLAN 1 , ID=WDNA1 4V6 . 

ATTACH , TAPE  1 6 , EXAMPLEPLAN2 , ID=WDNA 1 4V6 . 

CATALOG,  TAPE4',  EXAMPLEHISTVOL1  ,ID=WDNA14V6,RP=999. 
CATALOG , TAPEIO , FXAMPLEVOLl A , ID=WDNA1 4V6 , RP=999 . 
CATALOG ,TAPE1 1 , hXAMPLEVOLl B , ID=WDNA14V6 , RP=999. 

COMMENT  ***************************** ********** 
COMMENT.  *  VOLUME  2,  RUN  TYPE  EXAMPLE  * 

COMMENT  *************************************** 
ATTACH,  TAPE15,EXAMPLEV0L1A, ID=WDNA14V6. 

ATTACH, TAPE1 6, EXAMPLEVOL1 B , ID=WDNA14V6. 

CATALOG ,TAPE4 , EXAMPLEHISTVOL2 , IO=WDNA14V6 , RP=999. 
CATALOG , TAPEIO , EXAMPLEV0L2A , ID=WDNA 1 4V6 , RP=999 . 
CATALOG ,TAPE1 1 , EXAMPLEV0L2B , ID=WDNA1 4V6 , RP=999 . 

COMMENT  *************************************** 
COMMENT.  *  VOLUME  3,  RUN  TYPE  EXAMPLE  * 

COMMENT  *************************************** 
ATTACH , TAPE1 5 , EXAMPLEVOL2A , ID=WDNA1 4V6 . 

ATTACH , TAP  E 1 6 , EXAMP  LEVO  L2B , I D=WDNA 1 4V6 . 

CATALOG , TAPE4 , EXAMPLEHISTVOL3 , ID=WDNA ) 4V6 , RP=999 . 
CATALOG , TAPEIO , EXAMPLEVOL3A , ID=WONAl 4V6 , RP=999 . 
CATALOG ,TAPE1 1 , EXAMPLEV0L3B , ID=WDNA14V6 , RP=999. 

COMMENT  *************************************** 
COMMENT.  *  VOLUME  4,  RUN  TYPE  EXAMPLE  * 

COMMENT  *************************************** 
ATTACH , TAPE1 5 , EXAMPLEVOL3A , ID=WDNA1 4V6. 

ATTACH , TAPE16 , EXAMPLEVOL38 , ID=WDNA1 4V6 . 

CATALOG ,TAPE4 , EXAMPLEHISTV0L4 , ID=WDNA14V6 , RP=999. 
CATALOG , TAPEIO , EXAMPLEV0L4A , ID=WDNA14V6 , RP=999 . 
CATALOG, TAPE! 1 , EXAMPLEV0L4B , ID=WSNA14V6. RP=999. 


Figure  VI-10.  Volume  Cards 
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(2)  size  of  ISPACE  (100.000) 

(3)  maximum  number  of  players  on  either  side  (600) 

(4)  maximum  CPU  time  (in  decimal  seconds)  of  this  volume  (235) 

(5)  maximum  game  time  (in  decimal  seconds)  of  this  volume  (999999) 

(6)  maximum  number  of  events  for  this  volume  (20,000) 

This  particular  run  is  set  to  run  to  20,000  EVENTS,  since  game  time  and  CPU 
time  are  set  high.  To  get  even  volumes,  it  is  best  to  base  the  length  of 
the  volumes  on  number  of  events  or  CPU  time  rather  than  game  time.  To  use 
only  one  of  these  three  volume  length  control  parameters,  set  the  other  two 
unusually  high  so  that  the  desired  parameter  will  stop  the  volume  first. 


3. 


Post  Processor  Input 

After  all  volumes  of  the  main  processor  have  run,  the  post  pro¬ 


cessor  may  be  run  to  summarize  the  results  of  the  simulation.  The  pre¬ 


processor  and  each  volume  of  the  main  processor  saved  a  history  file. 
These  history  files  are  used  by  the  post  processor.  To  run  the  post  pro¬ 
cessor  for  our  four  volume  example  the  following  permanent  files  must 
reside  on  the  AFWL  system: 


MA0EMHISTBIN  -  post  processor  executable  program. 

EXAMPLEHISTPLAN  -  preprocessor  history  file 

EXAMPLEHISTV0L1  -  volume  1  history  file 

EXAMPLEHISTV0L2  -  volume  2  history  file 

EXAMPLEHISTV0L3  -  volume  3  history  file 

EXAMPLEHISTV0L4  -  volume  4  history  file 


If  the  preprocessor  and  the  main  processor  were  run  correctly,  then  all  the 
history  files  should  be  there. 


a.  Post  Processor  Job  Control  Language 

The  post  processor  job  control  stream  in  figure  VI-11  will 


produce  the  MADEM  post  processor  summary.  The  COMMENT  cards  are  for  your 
information  only  and  may  be  omitted.  The  ATTACH  cards  access  the  permanent 
files  listed  above.  Only  use  ATTACH  cards  for  the  files  needed.  That  is. 


MADEM, ST 1 76 , T20 , 1060 , P66 .  MADEM  HISTORY  PROCESSING  (EXAMPLE) 

ACCOUNT  MADEM, ******* ZZZ.BDM, 70^-821-4223.  B  MACALEER 

COMMENT  *************************************** 

COMMENT.  *  * 

COMMENT.  *  MADEM  HISTORY  PROCESSING  (EXAMPLE)  * 

COMMENT.  *  * 

COMMENT.  *  TAPE4:  CONCATENATION  OF  HISTORY  * 

COMMENT.  *  FILES  FROM  PREPROCESSOR  AND  * 

COMMENT.  *  ALL  VOLUMES  * 

COMMENT.  *  * 

comment  *************************************** 

ATTACH , H I  STB  I N , MAD  EMH I  STB  I N , I D=WDNA 1 4V6 . 

ATTACH .PLAN , EXAMPLEHISTPLAN , ID=WDNA14V6. 

ATTACH, VI .EXAMPLEHISTVOLl , 1D=WDNA1 4V6 . 

ATTACH ,V2 ,EXAMPLEH I STV0L2, ID=WDNA14V6. 

ATTACH , V3 , EXAMPLEHISTV0L3 , ID=WDNA 1 4V6 . 

ATTACH , V4 , EXAMPLEHI STVO  L4 , ID=WDNA 1 4V6 . 

ATTACH ,V5 , EXAMPLEHISTV0L5 , ID=WDNA14V6. 

ATTACH  ,V6 , EX AMPLEHISTV0L6, ID=WDNA14V6. 

ATTACH ,V7 .EXAMPLEHI STVO L7 , ID=WDNA14V6. 

ATTACH, V8 , EXAMP LEH I STVO L8 , ID=WDNA14V6. 

COPYBR .PLAN , TAPE4. 

COPYBR.Vl , TAPE4. 

COPYBR, V2.TAPE4. 

COPYBR, V3.TAPE4. 

COPYBR, V4.TAPE4. 

COPYBR, V5.TAPE4. 

COPYBR, V6.TAPE4. 

COPYBR, V7.TAPE4. 

COPYBR, V8.TAPE4. 

REWINO  ,TAPE4. 

LDSET,PRESET=ZERO. 

LOAD  .HISTBIN. 

EXECUTE. 

EXIT. 

COMMENT  *************************************** 

COMMENT.  *  WE  HAVE  BOMBED,  PRINT  HISTORY  INPUT  * 

COMMENT  *************************************** 

REWIND, TAPE4. 

C0PYSBF.TAPE4, OUTPUT. 

&  EOR 

CONVENTIONAL  1978  EXAMPLE  CASE 

39000. ,999999999. ,999999999. ,999999999. ,999999999. 

#  EOI 

Figure  VI-11.  Post  Processor  Job  Control  Language 
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if  only  four  volumes  of  the  main  processor  were  run,  then  delete  the  ATTACH 
cards  for  volumes  five  thru  eight.  Once  all  files  are  attached,  the  COPYBR 
cards  concatenate  all  the  history  files  into  one  local  file  called  TAPE4. 
Everything  after  the  EXIT  card  is  only  executed  if  the  system  abnormally 
aborts  the  job  stream.  In  this  case,  the  input  (TAPE4)  is  printed  to  use 
as  a  debuggi ng  too  1 . 

When  a  run  is  complete  through  the  post  processor,  there 
will  be  some  permanent  files  left  on  the  AFWL  system  that  are  no  longer 
needed.  These  files  should  be  purged  using  the  job  control  stream  that  is 
listed  in  Figure  VI-12.  Again,  use  only  the  purge  cards  corresponding  to 
the  number  of  volumes  that  were  run. 

b.  Post  Processor  Run  Parameters 

The  two  cards  before  the  last  card  are  Run  Parameter  Cards. 
The  first  parameter  card  is  an  up  to  70  character  header  that  will  appear 
on  the  output  summary.  The  second  parameter  card  holds  five  parameters. 
Each  of  these  five  parameters  represents  a  time  in  the  simulation  when 
summary  statistics  are  required.  The  time  is  a  real  number  and  is  in 
seconds.  In  this  example  we  are  requesting  only  one  set  of  summary  sta¬ 
tistics,  at  game  time  10.8  hours  (39000.0  seconds)  which  is  after  the  end 
of  the  simulation.  Therefore,  we  will  only  get  final  results  with  no 
intermediary  statistics.  When  more  than  one  "snapshot"  is  requested,  the 
snapshots  are  not  cumulative;  each  snapshot  covers  all  events  since  the 
previous  snapshot.  Up  to  five  snapshots  are  allowed.  If  less  than  five 
are  needed,  it  is  recommended  that  dummy  values  be  used  (999999999)  to 
suppress  further  processing,  as  was  done  in  this  example. 

0.  OUTPUTS 

Each  stage  of  the  MADEM  simulation  produces  some  useable  output.  The 
preprocessor  produces  the  Red  raid  plans,  the  main  processor  produces  an 
event  trace,  and  the  post  processor  produces  a  summary  of  the  events  of  the 
simulation. 
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MAOEM, ST1 76 , T40, 1040 , P66.  PURGE  HOLD  AND  HISTORY  FILES  (EXAMPLE) 

ACCOUNT  MADEM,  ,BDM, 703-821-4223.  B  MACALEER 

COMMENT  ******* *************** ***************** 

COMMENT-.  *  PURGE  HOLD  FILES  FOR  EXAMPLE  RUN  * 

COMMENT  ************************ ******* ******** 

PURGE, PL1 , EXAMPLEPLAN1 , ID=WDNA14V6 , LC=1 . 

PURGE ,PL2 , EXAMPLEPLAN2 , ID=WDNA14V6 , LC=1 . 

PURGE , VI A , EXAMPLEV0L1 A , ID=WDNA1 4V6 , LC=1 . 

PURGE , VI B , EXAMPLEV0L1B , ID=WDNA1 4V6 , LC=1 . 

PURGE , V2A , EXAMPLEV0L2A , ID=WDNA1 4V6 , LC=1 . 

PURGE , V2B , EXAMPLEV0L2B , ID=WDNA14V6 , LC=1 . 

PURGE , V3A , EXAMPLEV0L3A , ID=WDNA1 4V6 , LC= 1 . 

PURGE , V3B , EXAMPLEV0L3B , ID=WDNA14V6 , LC=1 . 

PURGE , V4A , EXAMPLEV0L4A , ID=WDNA1 4V6 , LC=1 . 

PURGE , V4B , EXAMPLEV0L48 , ID=WDNA1 4V6 , LC=1 . 

PURGE , V5A , EXAMPLEV0L5A , ID=WDNA1 4V6 , LC=1 . 

PURGE , V5B , EXAMPLEV0L5B , ID=WDNA1 4V6 , LC=1 . 

PURGE , V6A , EXAMPLEV0L6A , ID=WDNA1 4V6 , LC=1 . 

PURGE , V6B , EXAMPLEV0L6B , ID=WDNA1 4V6 , LC=1 . 

PURGE , V7A , EXAMPLEV0L7A , ID=WDNA1 4V6 , LC=1 . 

PURGE , V7B , EXAMPLEV0L7B , ID=WDNA14V6 , LC=1 . 

PURGE , V8A , EXAMP  LEVO  L8A , I D^WDNA 1 4V6 , LC= 1 . 

PURGE , V8B , EXAMPLEV0L8B , ID=WDNA1 4V6 , LC=1 . 

COMMENT  *************************************** 

COMMENT.  *  PURGE  HISTORY  FILES  FOR  EXAMPLE  RUN  * 

COMMENT  *************************************** 

PURGE , HP , EXAMPLEHISTPLAN , ID=WDNA1 4V6 , LC=1 . 

PURGE , HI .EXAMPLEHISTV0L1 , ID=WDNA14V6 , LC=1 . 

PURGE , H2 , EXAMP  LEHI STVO  L2 , ID=WDNA 1 4V6 , LC=1 . 

PURGE ,H3 , EXAMPLEHISTV0L3 , ID=WDNA1 4V6 , LC=1 . 

PURGE , H4 , EXAMPLEHISTV0L4 , ID=WDNA14V6 , LC=1 . 

PURGE ,H5 , EXAMPLEHISTV0L5 , ID=WDNA14V6 , LC=1 . 

PURGE ,H6 , EXAMPLEHISTV0L6 , ID=WDNA1 4V6 , LC=1 . 

PURGE ,H7 , EXAMPLEHISTV0L7 , ID=WDNA14V6 , LC=1 . 

PURGE , H8 , EXAMPLEHISTV0L8 , ID=WDNA1 4V6 , LC=1 . 

#  EOI 


Figure  VI-12.  Post  Run  Purging  JCL 
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A. 


1 .  Preprocessor  Output 

The  preprocessor  produces  three  types  of  printed  output:  an  echo 
of  the  Data  Base  File,  an  echo  of  the  User  Input  Lanaguage  File,  and  a 
description  of  the  Red  attack  plan  for  raid  one.  In  our  example  case,  the 
Red  attack  consisted  of  one  raid,  two  waves,  as  determined  by  the  UOIL 
File. 

The  first  part  of  the  red  planner  output  is  a  list  of  flight 
action  codes  with  their  respective  descriptions.  These  codes  are  used  in 
the  remainder  of  the  output  to  indicate  the  movements  and  actions  of  each 
flight  in  the  wave.  These  Flight  Action  Codes  are  also  listed  below: 

FLIGHT  ACTION  CODES: 

1  JAMMER  ON 

2  JAMMER  OFF 

3.  PROFILE  CHANGE  POINT 

4.  ECM  ORBIT 

5.  INTERCEPT  ORBIT 

6.  RENDEVU  POINT 

7.  GROUND  ATTACK  ORBIT 

8.  ASM  LAUNCH 

9.  STOP  ORBIT,  NEWCOURSE 

10.  LAND 

11.  CHANGE  COURSE 

These  actions  may  be  taken  at  the  end  of  each  leg  of  a  flight  path. 

The  rest  of  the  planner  output  consists  of  detailed  descriptions 
of  each  wave  in  raid  one,  beginning  with  the  last  wave.  For  each  target  of 
the  Red  attack,  its  hex  location  is  given  with  a  description  of  the  flight 
plans  for  each  formation  assigned  to  the  target.  There  is  one  line  of 
output  for  each  action  taken  by  each  flight.  There  are  twelve  fields  on 
each  line  of  output  (repetition  is  implied  with  blank  fields).  These 
fields  are  described  below: 

(1)  Target  Type  -  Numeric  code  indicating  the  type  of 

target.  See  Appendix  E  for  an  expla¬ 
nation  of  the  codes. 
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(2)  Target  Unit  Number 


Unit  number  of  a  specific  target.  These 
unit  numbers  are  derived  from  the  UOIL 
File.  If  the  unit  number  is  negative, 
that  means  the  target  is  passive. 

(3)  Target  Location  -  Hex  location  of  the  target. 

(4)  Formation  Type  -  Type  of  formation  assigned  to  the  tar¬ 

get.  These  formation  types  are  defined 
by  the  data  base  file. 

(5)  FI  ight  Unit  Number  -  Unit  number  of  a  flight  in  the  forma¬ 

tion.  These  unit  numbers  are  created  by 
the  simulation. 

(6)  Flight  Type  -  Indicates  the  type  of  flight  as  defined 

by  the  Data  Base  File. 

(7)  Number  of  Ai rcraft  -  Indicates  how  many  aircraft  are  in  the 

f 1 ight. 

(8)  Aircraft  Type  -  Numeric  code  indicating  the  type  of 

aircraft  in  the  flight.  All  fli-ghts  are 
homogeneous.  See  Appendix  E  for  an 
explanation  of  the  codes. 

(9)  Airbase  Unit  Number  -  Unit  number  of  the  airbase  that  the 

flight  originated  from.  This  number 
comes  from  the  UOIL  File. 

(10)  Airbase  Location  -  Hex  location  of  the  airbase  that  the 

flight  originated  from. 

(11)  Action  Hex  -  Hex  location  at  which  the  action  des¬ 

cribed  in  the  next  field  is  to  take 
place. 

(12)  Action  Code  -  Action  codes,  described  in  the  first 

page  of  planner  output,  that  describes 
flight  movements  at  the  given  hex  loca¬ 
tions. 
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a.  First  Wave  Attack  Plan 

The  first  wave  attack  plan  which  results  from  the  first  wave 
attack  specification  input  by  the  user  is  summarized  and  output  by  the 
preprocessor.  The  first  wave  plan  for  this  scenario  output  by  the  pre¬ 
processor  is  shown  in  figure  VI-13.  The  assignment  of  flights  from  various 
airbases  to  formations  and  subsequently  to  blue  targets  is  output  along 
with  the  flight  plans  for  each  flight. 

The  first  wave  attack  plan  shown  in  figure  VI-13  is  illus¬ 
trated  in  figure  VI-14.  Figure  VI-14  shows  the  courses  to  target  planned 
for  the  first  wave.  These  courses  indicate  planned  attacks  on  HAWK  and 
Ni ke-Hercul es  batteries  in  the  attack  corridors. 

b.  Second  Wave  Attack  Plan 

A  partial  listing  of  the  second  wave  attack  plan  output  is 
shown  in  figure  VI-15.  The  same  plan  is  illustrated  in  figure  VI-16.  Both 
figures  indicate  planned  attacks  on  HAWK  batteries  near  the  attack  cor¬ 
ridors  and  upon  airbases  and  passive  targets  deep  in  blue  airspace. 
Several  large,  formation  rendevous  points  are  also  indicated  within  red 
airspace. 

2.  Main  Processor  Output 

The  main  processor  produces  a  printed  event  trace  while  the 
simulation  is  in  progress.  Only  pertinent  events  produce  an  event  trace. 
Since  about  ninety  percent  of  the  simulation  events  are  trival  (but 
necessary)  only  about  one  event  in  ten  produces  a  printed  trace. 

The  event  trace  messages  are  explained  in  Appendix  B.  To  the 
left  of  each  event  message  is  the  game  time,  in  seconds,  at  which  the  event 
occurred.  See  figure  VI-17  for  a  sample  event  trace. 

3.  Post  Processor  Output 

The  MAOEM  postprocessor  outputs  a  variety  of  information  designed 
to  aid  analysts  in  computing  measures  of  air  defense  effectiveness.  These 
outputs  are  in  the  form  of  tables  which  contain  the  following  information: 

(1)  Units  created  by  type 

(2)  Red  attacks  on  Blue  players  by  aircraft  type 
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Figure  VI-13.  Result  Of  Red  Theater  Plans 


Figure  VI-14.  First  Wave  Attack  Plan 
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(3)  Red  attacks  on  Blue  passive  targets  by  aircraft  type 

(4)  Acquisitions  of  Red  flights  by  blue  units 

(5)  Red  flights  engaged  by  Blue  defense  units 

(6)  Red  aircraft  killed  by  Blue  defense  units 

(7)  Missiles  fired  by  unit  type 

These  table  are  displayed  in  three  formats.  The  first  format  is  used  only 
for  units  created  and  is  illustrated  in  Figure  VI-18.  The  second  format 
type  is  used  for  Red  attacks  on  Blue  players,  Red  attacks  on  Blue  passive 
targets,  and  Red  aircraft  killed  by  Blue  defense  units.  This  format  is 
illustrated  in  figure  VI-17.  The  "231"  in  the  uper  left  hand  corner  of  the 
output  matrix  in  Figure  VI-19  is  an  internal  matrix  code  number.  It  can  be 
ignored  in  the  analysis  of  MADEM  output.  Column  1  and  Row  1  of  the  matrix 
in  Figure  VI- 19  indicate  the  unit  code  numbers  of  attacking  red  flights  and 
defending  Blue  units  respectively. 

Figure  VI-20  illustrates  the  format  used  to  display  acquisitions 
of  Red  flights  by  Blue  units,  Red  flights  engaged  by  Blue  units, and 
missiles  fired.  This  format  is  identical  to  figure  VI-19  except  for  the 
addition  of  row  and  column  totals  indicated  by  a  9999  in  Row  1  and  Column 
1. 
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TYPE  NUMBER 


34 

1 

130 

2 

150 

2 

160 

2 

170 

6 

180 

4 

210 

4 

220 

8 

401 

12 

420 

11 

440 

16 

460 

11 

NOTE:  SEE  APPENDIX  E  FOR  UNIT  CODE  DEFINITIONS 


Figure  VI-18.  Number  Of  Units  Created  By  Type 
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DOEE  DOER 


231 

440 

420 

460 

170 

6 

0 

0 

401 

10 

28 

0 

220 

3 

0 

4 

NOTE:  DOER  =  SUBJECT  OF  AN  ACTION 
DOEE  =  OBJECT  OF  AN  ACTION 

SEE  APPENDIX  E  FOR  DOER/DOEE  UNIT  CODE  DEFINITIONS 


Figure  VI-19.  Number  Of  Red  Attacks  On  Blue  Players 
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APPENDIX  A 

USER  GUIDE  TO  HEXAGONAL  COORDINATE  SYSTEM 


A.  INTRODUCTION 


The  purpose  of  this  appendix  is  to  give  a  brief  explanation  of  the 
Hexagonal  Coordinate  System  (HECS)  used  in  MADEM.  For  a  more  detailed 
discussion,  including  the  rationale  for  using  this  coordinate  system,  the 
reader  is  referred  to  the  draft  technical  report,  "An  Integrated  Coordinate 
System  for  Combat  Modeling",  BDM/W-78-297-TR,  19  May  1978. 

B.  STRUCTURE  OF  HECS 


The  Hexagonal  Coordinate  System  is  based  upon  the  concept  of  tiling 
the  plane  with  a  grid  of  regular  hexagons  and  aggregating  them  into  suc¬ 
cessively  larger  clusters  of  7.  A  single  regular  hexagon  in  the  grid  is 
called  a  level  0  hex.  A  cluster  of  7  level  0  hexes,  one  regular  hexagon 
together  with  its  6  neighboring  hexagons,  is  called  a  level  1  hex.  This 
process  of  aggregation  can  be  iterated,  and  in  general  a  cluster  of  6  level 
n  hexes  surrounding  a  central  level  n  hex  forms  a  level  n  +  1  hex. 

The  higher  level  hexes  are  not  true  regular  hexagons,  but  they  remain 
approximately  hexagonal  in  shape.  Hexes  at  any  level  mesh  together  to  tile 
the  plane. 

C.  MADEM  AIRSPACE 

The  MADEM  airspace  is  represented  by  a  single  level  12  hex.  This  hex 
contains  7  level  11  hexes,  each  of  which  contains  7  level  10  hexes,  and  so 
on  down  to  the  level  0  hexes,  which  are  regular  hexagons.  The  grid  is 
oriented  so  that  the  level  0  hexes  have  a  pair  of  opposite  edges  running 
west  to  east.  The  lowest  level  Hex  used  in  MADEM  is  a  level  6  Hex  which 
measures  9.45km  from  face  to  face.  Each  unit  (including  Flights)  is 
located  in  a  level  6  Hex. 


HEX 

LEVEL 

NO.  OF 

HEX  DIAMETER 

HEX  AREA 

DEC 

OCT 

HEX  DIGITS 

(KM) 

Dz  N3  /2 

13 

15 

0 

8575. 

63,700,000 

12 

14 

1 

3240. 

9,100,000 

11 

13 

2 

1225. 

1,300,000 

10 

12 

3 

463. 

185,600 

9 

1 1 

4 
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26  500 

8 

10 

5 

66.  1 

3,790 

7 

7 

6 

25. 

541 

6 

6 

7 

9.45 

77 

Figure  A- I.  Hex  Specifications 


8 


D.  HEX  ADDRESSES 


A  hex  address  is  a  string  of  one  to  twelve  digits  which  identifies  a 
specific  hex.  It  is  a  way  of  encoding  both  the  location  and  the  level  of  a 
hex.  Each  digit  in  a  hex  address  is  from  1  through  7  inclusive.  The 
leftmost  digit  identifies  which  of  the  7  level  11  hexes  contains  this  hex. 
If  there  are  no  further  digits,  then  the  hex  address  corresponds  to  this 
level  11  hex.  The  next  digit  identifies  which  of  the  7  level  10  hexes 
comprising  the  level  11  hex  contains  the  hex  in  question.  This  classifi¬ 
cation  procedure  continues  all  the  way  down  to  the  level  of  the  specificed 
hex.  The  hex  address  of  a  level  0  hex  will  have  12  digits,  and  in  general 
the  following  equation  is  satisfied: 

L  +  D  =12 

where  L  is  the  level  of  the  hex  and  D  is  the  number  of  digits  in  its  hex 
address. 

The  numbering  scheme  for  a  level  7  cluster  of  7  level  6  hexes  is  shown 
in  Figure  A-2.  Note  that  7  indicates  the  center  hex  and  1  indicates  the 
hex  directly  north  of  center.  The  rest  of  the  numbering  scheme  is  chosen 
for  computational  convenience.  The  numbering  scheme  for  a  level  8  cluster 
of  7  level  7  hexes  is  shown  in  A-3.  The  scheme  is  essentially  the  same 
except  that  there  has  been  a  slight  counterclockwise  rotation  of  the  posi¬ 
tions  of  the  hexes  numbered  1  through  6.  For  clusters  of  higher  and  higher 
level  hexes,  the  same  numbering  scheme  is  used,  but  the  relative  positions 
of  the  outer  hexes  rotate  approximately  19  degrees  counterclockwise  for 
each  increase  in  level. 

Figure  A-4  illustrates  the  combined  numbering  scheme  for  level  6  hexe. 
within  a  level  8  hex.  The  two  digits  shown  would  be  the  last  2  digits  in 
the  hex  addresses  for  these  level  6  hexes.  Note  that  the  shaded  level  6 
hex  is  numbered  35  because  it  is  in  the  5  position  within  the  number  3 
level  7  hex  in  the  level  8  cluster.  Figure  A-5  shows  a  few  sample  hex 
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Figure  A-4.  Combined  Numbering  Scheme  For  Level  6  Hexes 
Within  A  Level  8  Cluster 


addresses  in  a  level  9  cluster.  Actually  each  address  would  be  preceded  by 
a  digit  identifying  the  particular  level  9  hex  illustrated. 


E.  HEX  DIRECTIONS 


Movement  is  always  in  the  direction  of  one  of  the  six  surrounding 
hexes  of  the  same  level.  The  directions  are  identified  by  the  same 
numbering  scheme  as  used  for  creating  hex  addresses.  Thus,  at  each  level, 
the  hex  direction  7  represents  a  null  direction  signifying  no  movement,  and 
there  are  6  equally  spaced  hex  directions  numbered  1  through  6.  A  level  0, 
hex  direction  1  corresponds  to  north,  but  it  undergoes  a  counterclockwise 
rotation  of  about  19  degrees  for  each  higher  level.  Figures  A-6  and  A- 7 
illustrate  the  hex  directions  at  levels  6  and  7. 


APPENDIX  B 


MADEM  DISPLAYED  EVENTS 


As  events  occur  in  the  model  a  message  will  be  printed  to  symbolize 
what  is  happening  in  the  model.  These  event  messages  originate  out  of  the 
subroutines.  The  variable  numbers  that  are  printed  out  in  the  message  are 
denoted  here  by  *N0. 

The  following  is  a  list  of  the  event  messages  and  the  subroutines 
associated  with  it.  In  the  list  below,  the  Source  column  shows  the 
initiator  of  the  event  and  is  the  key  to  the  format  of  the  event  message 
print  out.  The  events  are  printed  in  three  columns:  the  first  column  is 
the  Red,  the  second  is  the  CRC/AB  and  the  third  is  the  BOC/BTRY. 


Subrouti ne 

Source 

Message 

AB2CRC 

CRC/AB 

CRC/AB 

CRC  *N0  ACKS  LAUNCH  OF  INT  *N0 

CRC  *N0  ACKS  LANDING  OF  INT  *N0 

ABSEE 

CRC/AB 

CRC/AB 

A/B  *N0  ACKS  LANDING  REQUEST  FROM  INT  *N0 

A/8  *NQ  ACKS  REQUEST  FOR  INTERCEPTORS  BY  *N0 

ACCEPT 

BOC/BTRY 

B0C/8TRY 

UNIT  *NQ  PLACES  FLIGHT  *N0  ON  FOQ 

UNIT  *N0  RECEIVES  ORDER  TO  ENGAGE  FLIGHT 

*N0  WITH  *NO  FIRE  UNITS 

AIRTHNK 

RED 

CRC/AB 

FLT  *N0  TYPE  *  NO  ENGAGES  *N0 

INT  *N0  ENGAGE  *N0  RELEASING  *N0 

ALLOBAT 

BOC/BTRY 

BOC/BTRY 

BTN  *N0  ASSIGNING  BATTERY  *N0  *N0  (*NO) 

UNITS  OF  COVERAGE  ON  FLIGHT  *NO 

BTN  *N0  PLACES  FLIGHT  *N0  ON  PDIL 
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Subroutine 


Source 


ALLOFU 

ALLOPAT 

AMMOCHK 

ATKASES 


BNCONHD 

BNCONTC 

BNNOTRD 

BNP0NB8 

BNP0N8D 

BNPONFA 

BNPONFD 


Message 


BOC/BTRY  FIRE  UNIT  *NO  OF  BTRY  *NO  ASSIGNED  TO  FLIGHT 

*NO 

BOC/BTRY  BTRY  *NO  TAKES  ENG  *NO  (*NO)  AGAINST  FLT 

*NO 

BOC/BTRY  BATTERY  *NO:  FIREUNIT  *NO  EMPTY 

RED  FLT  *NO  DESTROYS  TGT  *NO  TYPE  *NO 

RED  FLT  *NO  REPORTS  *NO  TYPE  AND  HAS  *NO  DAMAGE 

RED  FLT  *NO  WILL  BE  SHOT  FOR  MISSING  *NO  TYPE 

*NO 

BOC/BTRY  BTN  *NO  PONDERS  HEADING  CHANGE  BY  FLIGHT 

*NO 

BOC/BTRY  BTN  *NO  PLACES  FLIGHT  *NO  ON  PDIL 

BOC/BTRY  BTN  *NO  NOW  IMPOTENT 

BOC/BTRY  BTN  *NO  WELCOMES  ABOARD  BTRY 

BOC/BTRY  BTN  *NO  MOURNS  THE  UNTIMELY  DEATH  OF  BATTERY 

(*NO) 

BOC/BTRY  BTN  *NO  SAVORS  THE  DEATH  OF  *NO  A/C  IN  FLIGHT 

*NO 

BOC/BTRY  BTN  *NO  CELEBRATES  TOTAL  ANNIHILATION  OF 

FLIGHT  *NQ 


188 


Subroutine 


Source 


Message 


BOCTINK 

BOC/BTRY 

BTN  *NO  GIVES  UP  ON  FLIGHT  *N0 

BTNASIN 

CRC/AB 

CRC  *NO  ASSIGNS  *NO  TO  BTN  *NO 

BTN2CRC 

CRC/AB 

CRC  *NO  ACKS  RLSE  OF  TGT  *NO  BY  BTN  *NO 

CRC/AB 

CRC  *NO  ACKS  DEATH  APT  ON  *NO  BY  BTN  *NO 

CRC/AB 

CRC  *NO  ACKS  LOSS  OF  TGT  TRK  *NO  BY  BTN  *NO 

BTRYTNK 

BOC/BTRY 

BATTERY  *NO  GIVES  UP  ON  FLIGHT  *NO 

BOC/BTRY 

BTRY  *NO  LOSES  TRACK  *NO  (MASK  =  *NO) 

BYALCOV 

BOC/BTRY 

BTRY  *NO  NOW  TO  COVER  FLIGHT  *NO  WITH  *NO 

FIRE  UNITS 

BYCMDPR 

BOC/BTRY 

BTRY  *NO  RELEIVES  CEASE  ORDER  FOR  FLIGHT  *NO 

BYCONHD 

BOC/BTRY 

BATTERY  *NO  PONDERS  HEAOING  CHANGE  BY  FLIGHT 

*NO 

BYNOTRD 

BOC/BTRY 

BATTERY  *NO  AWAITING  RELOAD 

BYPONRL 

BOC/BTRY 

BTRY  *NO:  FIRE  UNIT  *NO  LOADED  *NO  TYPE  *NO 

MISSILES 

BYPONRS 

BOC/BTRY 

BTRY  *NO  RESUPPLIED  —  *NO  MISSLES 

BYPONTM 

BOC/BTRY 

FLIGHT  *NO  TRACKED  BY  BATTERY  *NO 

CANCALO 

BOC/8TRY 

FIRE  UNIT  *NO  OF  BTRY  *NO  CEASES  FIRE  ON 

FLIGHT  *NO 

BOC/BTRY 

BTRY  *NO  CEASES  ONE  ENGAGEMENT  OF  FLT  'NO 

('NO) 
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Subroutine 


Source 


Message 


CHKCOV  RED  POSSIBILITY  —  *NO 


COMMAND 

RED 

FLT  *NO 

RED 

FLT  *NQ 

RED 

FLT  *NO 

RED 

FLT  *NO 

RED 

FLT  *NQ 

RED 

FLT  *NO 

CRC2INT 

CRC/AB 

INT  *NO 

CRC/AB 

INT  *NO 

CRC/AB 

INT  *NO 

CRC  *NO 

CRC/AB 

INT  *NO 

CRC/AB 

INT  *NO 

CRCKIL 

CRC/AB 

CRC  *NO 

CRC/AB 

CRC  *NO 

CRC/AB 

CRC  *NO 

CRCEVNT 

CRC/AB 

CRC  *NO 

CRC/AB 

CRC  *NO 

CRC/AB 

CRC  *NO 

CRCTRAK 

CRC/AB 

CRC  *NO 

CRC/AB 

CRC  *NO 

DECRALO 

BOC/BTRY 

BTN  *NO 

TYPE  *NO  DIVES  TO  *NO  METERS 
TYPE  *NQ  CLIMBS  TO  *NO  METERS 
TYPE  *NO  AT  RENDEZVOUS  POINT 
TYPE  *NO  STRT  GND  ATK  ORB  IN  *NO 
TYPE  *NQ  REQUEST  LANDING  AT  *NO 
TYPE  *NQ  HEADS  FOR  HEX  *NO 

ACKS  RTN  TO  A/B  ORDR  FRM  CRC  *NO 

ACCEPTS  TARGET  *NO 

REJECTS  ASSIGNMENT  OF  TARGET  *NO  BY 

ACKS  NEW  INTERCEPT  VECTOR 
ACKS  BREAKOFF  MSG  FOR  TARGET  *NO 

PONDERS  DEATH  OF  *NO 
PONDERS  DEATH  OF  INT  *NO 
MARKS  TGT  *NO  UNASSIGNED 

DETECTS  DEATH  OF  *NO 
ACQUIRES  FLT  *NG 
LOSES  FLT  *NO 

SCRAMBLES  INTERCEPTORS  AT  ALL  A/B 
CORRECTS  MISID  OF  *NO 

ORDERS  BTRY  *NO  TO  REDUCE 


OESTROY 


RED 


XXXXXXXXXXXXXXXXXX  UNIT  *NO  IS  DEAD 
XXXXXXXXXXXXX 


Subrouti ne 


Source 


Message 


OETECT 

BOC/BTRY 

UNIT  *NQ  NOW  SEES  *NO 

BOC/BTRY 

UNIT  *NO  MASKED  FROM  *NO 

BOC/BTRY 

UNIT  *NO  LOSES  SIGHT  OF  *NO 

DOGFIGHT 

CRC/AB 

INT  *NO  FIRES  ON  *NO 

RED 

FLT  *NO  TYPE  *NO  RELEASES  A/G  ORD 

RED 

*NG  HAS  *NQ  A/C  REMAINING  OUT  OF  *NO 

RED 

FLT  *NO  BLOWS  INT  *NO  AWAY 

CRC/AB 

INT  *NO  BLOWS  FLT  *NO  AWAY 

OOGTHNK 

RED 

FLT  *NO  TYPE  *NO  OUT  OF  A/A  AMMO 

CRC/AB 

INT  *NO  OUT  OF  AMMO 

ENGAGE 

BOC/BTRY 

FIRE  UNIT  *NO  OF  BTRY  *NO  LOCKED  ON  FLIGHT 

*NO 

BOC/BTRY 

FIRE  UNT  *NO  OF  BTRY  *NO  FIRES  ON  FLIGHT  (NO 
(*NO) 

FILERUP 

BOC/BTRY 

UNIT  *NO  MISREADS  LOYALTY  OF  FLT  *NO 

FLY 

RED 

FLT  *NO  TYPE  *NO  CRASHS  DUE  TO  FUEL 

CRC/AB 

INT  *NQ  CRASHES  DUE  TO  LOW  FUEL 

FLYSEE 

CRC/AB 

INT  *NO  DETECTS  ASSIGNED  TARGET  *NO 

RED 

FLT  *NO  TYPE  *NO  DETECTS  DEATH  OF  AIR  TGT 

*NO 

FUELCK 

CRC/AB 

INT  *NO  HEADS  FOR  A/B  DUE  TO  LOW  FUEL 

RED  FIT  *N0  TYPE  *N0  GOES  HOME  DUE  TO  LOW  FUEL 
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Subrout i ne 


Source 


GN0L00K 

GOGETEM 

INT2CRC 


INTASIN 

INTFIND 

INTRFLY 

NEWMOVE 

NUKBLND 

READIL 


Message 


RED 

RED 

RED 

RED 


FLT  *NQ  DETECTS  GND  TGT  *NG 
FLT  *NO  OVERLOOKS  GND  TGT  *NO  IN  *NO 
FLT  *NO  DISCOVERS  TGT  *NO  NOT  IN  *NO 
FLT  *NO  TYPE  *NO  ABORTS  GROUND  ATTACK 


CRC/AB 


A/B  *NQ  LAUNCHS  INTRCPTR  *NO 


CRC/AB 

CRC/AB 

CRC/AB 


CRC  *NO  ACKS  INT  *NO  AVAIL  -  DEAD  TARGET  *NO 

CRC  *NO  ACKS  INT  *NO  AWAITING  ORDERS 

CRC  *NO  ACKS  ACQUISITION  BY  INT  *NO  OF  TARGET 

*NO 


CRC/AB 

CRC/AB 

CRC/AB 


CRC  *NO  ACKS  NONAVAIL  MSG  FRM  INT  *NO 

CRC  *NO  ACKS  MISID  OF  TGT  *NO 

CRC  *NO  ACKS  REFUSAL  OF  TGT  *NO  BY  INT-  *NO 


CRC/AB 

CRC/AB 


CRC  *NO  ASSIGNS  *NO  AGAINST  *NO 

CRC  *NO  SCRAMBLES  INTERCEPTRS  AT  A/B  *NO 


RED 


FLIGHT  *NQ  DETECTS  ASSIGNED  TGT  *NO  AT  TIME 
*NO 


CRC/AB 

CRC/AB 


INT  *NO  REQUESTS  LANDING  FROM  A/B  *NO 
INT  *NO  RETURNS  TO  A/B  *NO  FOR  CAP 


CRC/AB 

RED 

BOC/BTRY 


CRC  *NO  MISTAKES  IFF  OF  *NO  SIDE  *NO 


UNIT  *NO  COMMO  IS  DEAD  +++++ 


BTN  *NO  RETURNING  FLIGHT  *NO  TO  AOIL 
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Subrouti ne 

Source 

Message 

RONDSEE 

RED 

RENDEVOUS  COMPLETE  -  CORRIDOR  HEX  *NQ 

SAMATON 

BOC/BTRY 

UNIT  *NO  GOES  AUTONOMOUS 

SDIGEST 

BOC/BTRY 

UNIT  *NO  DIGESTS  INFO  ON  FLIGHT  *NO 

BOC/BTRY 

UNIT  *NG  MISREADS  LOYALTY  OF  FLT  *NO 

SHRKILL 

CRC/AB 

FLT  *NO  TYPE  *NO  LOSES  1  A/C  TO  SHORADS  AT 

*NO 

RED 

FLT  *NO  TYPE  *NO  KILLED  BY  SHORADS  AT  HEX 

TOAOIL 

BOC/BTRY 

UNIT  *NO  MOVING  FLIGHT  *NO 

TOWER 

RED 

RED  A/B  *  NO  LAUNCHS  FLT  *NO 

RED 

RED  A/B  *NO  LANDS  FLT  *NO 

CRC/AB 

A/B  *NQ  LANDS  INT  *NO 

TRYSHOT 

BOC/BTRY 

BTRY  *NO  HAS  NO  AMMO  USEABLE  AGAINST  FIT  *NO 

BOC/BTRY 

BTRY  *NO  DISCOVERS  FLIGHT  *NO  OUT  OF  ALTITUDE 

LIMITS 

UMPIRE 

BOC/BTRY 

FIRE  UNIT  *NO  OF  BTRY  *NO  VS  FLIGHT  *NO  — 

KILL  ### 

YANK 

RED 

BLOOOODDDYYY  MURDER 

APPENDIX  C 


COMMAND  AND  CONTROL  MESSAGE  LIST 

Communication  events  are  the  sending  of  messages  from  one  player  to 
another.  These  messages  originate  in  the  subroutines.  There  is  a  code 
number  associated  with  each  message  type. 

The  following  is  a  list  of  the  messages  and  the  subroutines  they  occur 
in.  The  message  is  not  printed  out  in  this  form,  it  is  the  interpretation 
of  it.  For  a  list  of  the  event  messages  printed  as  output  see  Appendix  B. 

Event  No.  Code  Subrouti ne  Message 

25650001  1320  AIRTHNK  Schedule  msg.  to  live  CRC  of  availability 

25690001  1320  AIRTHNK  Report  from  interceptor  to  CRC  that 

interceptor  is  goint  to  engage  a  target 
of  opportunity 

25690001  2831  ALL0BAT  Order  from  B0C  to  BTRY  to  attempt  to 

engage  a  particular  flight 

25690001  2834  ALL0BAT  Order  from  B0C  to  BTRY  increasing 

assigned  coverage  level  against  a 
particular  flight 

25340001  2751  AMM0CK  Report  from  BTRY  to  B0C  that  assigned 

flight  can  no  longer  be  engaged  due  to 
lack  of  appropriate  type  of  ammo 

25690001  1500  BA0M0VE  Schedule  breakoff  message  to  interceptor 
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Event  No 

256900C 

25690001 

25690001 

25690001 

25690001 

25690001 

25690001 

25120001 

25690001 


Code 


Subrouti ne 


Message 


1520 


BA0M0VE 


Update  from  CRC  to  interceptor  on  course 
of  assigned  flight 


2835 


BNCONHD 


Update  from  BOC  to  BTRY  on  course  of 
assigned  flight 


1600 


BNCONLS 


Report  from  BOC  to  CRC  that  assigned 
flight  has  been  lost  to  sight 


1600 


BNCMDPR 


Report  from  BOC  to  CRC  indicating 
assignment  cannot  be  accepted  because 
no  assets  ready  for  action 


2761 


BNLALLE 


Report  from  BOC  to  CRC,  or  from  BTRY 
to  BOC,  indicating  no  projected  oppor¬ 
tunity  to  engage  assigned  flight 


2832 


BNPONEP 


Order  to  BTRY  to  cease  fire  on  a  partic¬ 
ular  flight 


1600 


BOCTINK 


Report  from  BOC  to  CRC  that  assigned 
flight  was  not  sighted 


2731 


2762 


BTNASIN 


BTRYTNK 


Order  from  CRC  to  BOC  to  attempt  to 
engage  a  particular  flight 

Report  from  BTRY  to  BOC  that  assigned 
flight  was  not  sighted  as  expected 
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Event  No. 

Code 

Subrouti ne 

Messaqe 

25690001 

2762 

BYCONLS 

Report  from  BTRY  to  B0C  that  assigned 
flight  has  been  lost  to  sight 

25690001 

2762 

8YC0NTL 

Report  from  BTRY  to  B0C  that  assigned 
flight  has  changed  course 

25690001 

2761 

BYHEDUP 

Report  from  BTRY  to  B0C  that  BTRY  no 
longer  has  a  projected  opportunity  to 
engage  an  assigned  flight 

25690001 

2762 

BYNWTRK 

Report  from  BTRY  to  B0C  that  assigned 
flight  was  changed  course 

25690001 

2780 

BYPONER 

Report  from  BTRY  to  B0C  on  attrition  of 

assigned  flight 

25690001 

2790 

BYP0NFD 

Report  from  BTRY  to  B0C  on  total  destruc¬ 
tion  of  flight 

25690001 

2752 

BYP0NRL 

Report  from  BTRY  to  BOC  on  ammo  reload 

25390001 

1984 

COMMAND 

Landing  request  from  aircraft  to  airbase 

25690001 

1310 

CRC2INT 

Report  from  interceptor  to  CRC  that 
interceptor  is  available  for  assignment 

25650001 

1330 

CRC2INT 

Schedule  msg  to  CRC  can't  accept 
assignment 

25650001 

1312 

CRCTRAK 

Order  from  CRC  to  airbase  to  scramble 

interceptors 
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Event  No. 

Code 

Subroutine 

Message 

25690001 

2832 

DECRALO 

Order  from  BOC  to  BTRY  to  cease  fire  on 

a  particular  f 1 ight 

25690001 

2834 

DECRALO 

Order  from  BOC  to  BTRY  decreasing 
assigned  coverage  level  against  a 
particular  flight 

25690001 

1340 

DOGTHNK 

Report  from  interceptor  to  CRC  that 
interceptor  is  out  of  air-to-air  ammo 
and  is  returning  to  base 

25690001 

2832 

DROPPOS 

Order  from  BOC  to  BTRY  to  cease  fire  on 

a  particular  flight 

25690001 

2832 

DR0PPS2 

Order  from  BOC  to  BTRY  to  cease  fire  on 

a  particular  f 1 ight 

25650001 

1300 

FLYSEE 

Report  from  interceptor  to  CRC  that  cur 
rent  target  is  destroyed,  and  inter¬ 
ceptor  is  available  for  another 

assignment 

25390001 

1340 

FUEICHK 

Report  from  interceptor  to  CRC  that 
interceptor  is  returning  to  base  for 

fuel 

25120001 

1312 

INTASIN 

Request  interceptor  launch 

25120001 

1510 

INTASIN 

Message  to  interceptor  of  assignment 

Event  No. 

Code 

Subroutine 

Message 

25620001 

1330 

INTFIND 

Message  to  CRC 

reporting  direction 

25390001 

1310 

INTERFLY 

Request  orders 

from  CRC 

25390001 

1984 

INTRFLY 

Landing  request 

ai rbase 

from  interceptor  to 
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APPENDIX  D 


THE  AFWL  SYSTEM 


MADEM  uses  either  of  2  computers  at  AFWL,  the  Y  mainframe  (MFY)  or  the 
X  mainframe  (MFX).  Both  are  CDC  Cyber  176  machines.  We  generally  run  on 
MFY  since  our  remote  terminal  has  a  direct  line  there,  but  we  can  run  on 
either.  It  is  possible  to  use  a  dial  up  terminal  for  either  batch  or 
interactive  service  using  the  following  phone  numbers. 


BAUD  RATE 

MFY 

MFX 

300 

505-264-2082(3) 

505-842-5162 

(17) 

300 

-- 

505-842-9980 

(10) 

300 

-- 

505-264-5875 

(3) 

300 

-- 

505-264-9861 

(3) 

1200 

505-264-5840  (3) 

505-264-5705 

(3) 

4800 

505-264-7812  (3) 

-- 

4800 

505-842-6392  (2) 

505-842-6391 

(4) 

4800 

-- 

505-842-5711 

(6) 

The  number  in  parenthesis  is  the  number  of  lines  on  that  rotary.  MADEM 
cannot  run  on  MFB  because  of  the  extended  core  requirements  of  MADEM. 

1 .  AFWL  Operating  System 

AFWL  runs  on  the  NOS/BE  1.2  operating  system.  The  correct  manual 
for  this  operating  system  is  the  CDC  manual  60493800. 

Intercom  4.1  is  the  operating  system  that  interfaces  remote 
terminals  (batch  or  interactive)  with  the  mainframes.  Ths  manual  for  this 
is  the  CDC  manual  60494600. 

2.  Using  AFWL  from  BDM  -  Washington 

We  have  a  data  100  remote  batch  terminal  that  has  a  direct  line 
(4800  8AU0)  to  AFWL's  MFY.  We  can  also  dial  up  from  another  terminal,  but 
we  generally  use  the  Data  100. 


P&CKD1M  Page  BUNK-WOT  hud 

* 


201 


T 


а.  Using  the  Data  100 

To  bring  up  the  Data  100: 

1.  Load  Emulator  -  Read  in  "DATA  100"  cards  by  pressing 
"HALT",  then  "LOAD".  After  cards  have  been  read  press 
"RUN". 

2.  Press  XMIT  button  -  XMIT  light  on  is  for  029  keypunch. 

3.  Wait  for  "DATA  LINK"  light. 

4.  Before  entering  each  command,  press  Control-A. 

5.  Type  "LOGIN,  SGCBDM,  WDNA14V6,  SUP" 

б.  Wait  for  "COMMAND"  message. 

7.  Type  "C". 

To  Enter  Cards: 

1.  Load  cards. 

2.  Press  START 

3.  Type  "R"  when  reader  stops. 

To  turn  on  line  printer  type  "QN,LP". 

3.  AFWL  JCL  Notes 

a.  AFWL  Job  Card 

The  first  card  in  a  JCL  deck  is  a  job  card. 

Example:  MA0EM,  ST176,  T40,  1037,  P66. 

MADEM  -  can  be  any  name,  first  five  characters  used  as 

first  five  characters  of  seven  character  job  name. 
ST176  -  Tells  it  to  run  on  either  Cyber  176  (MFY  or  MFX). 

Can  also  use  STMFX  of  STMFY  to  run  on  a  particular 
mac hi ne. 

T40  -  CPU  time  limit  in  octal  seconds. 

1037  -  10  time  limit  in  octal  seconds. 

P66  -  Request  for  66  priority.  The  highest  priority 

allowed.  The  priority  is  dependent  on  10  and  CPU 
time  requested. 
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P66  IO+CPU  is  less  than  100  octal 
P60  IO+CPU  is  less  than  400  octal 
P50  IO+CPU  is  less  than  1,000  octal 
P40  none 

P30  CP  is  less  than  1000B 
P20  CP  is  less  than  2000B 
P10  CP  is  less  than  4000B 

b.  AFWL  Account  Card 

The  second  card  in  a  JCL  deck  is  the  account  card.  j 

Example:  ACCOUNT  MADEM,  XXXXXXXX-ZZZ ,  BDM, 703-821 -4223.  j 

ACCOUNT  -  Card  identifier  j 

MADEM  -  means  nothing,  can  be  any  name. 

XXXXXXXX  account  ID 

111  ~  account  password. 

BDM  -  not  needed,  but  it  identifies  us.  >1 

703-821-42 23  -  not  needed,  but  enables  us  to  be  reached  by 
this  phone  number  in  case  a  problem  occurs. 

c.  End-of-Record  Cards  i 

To  separate  the  JCL  from  the  INPUT  File,  or  to  separate  two  - 

INPUT  Files,  use  an  End-of-Record  (E0R)  card.  The  E0R  card  is  a  multi¬ 
punch  7/8/9  in  column  one.  When  submitting  jobs  interactively,  the  system  1 

will  interpret  *E0R  as  an  E0R  card.  In  some  of  our  JCL  examples  in  this  ; 

manual  ,  an  E0R  card  is  represented  by  a  in  column  one. 

d.  End-of- information  Cards  1 

At  the  end  of  an  entire  input  stream  (that  is,  JCL  and  any 

INPUT  Files)  use  an  End-of- Information  (E0I)  card.  The  E0I  card  is  a  j 

multi-punch  6/7/S/9  in  column  one.  When  submitting  jobs  interactively,  the  j 

system  will  interpret  *E0I  as  an  E0I  card.  In  some  of  the  JCL  examples  in  j 

this  manual,  the  E0I  card  is  represented  by  a  in  column  one. 

4.  Large  Permanent  Files  at  AFWL 

Any  permanent  file  larger  than  35  RB's  (  1960  PRU's)  wi  1 1  be  i 

routinely  purged  at  AFWL.  I ; 
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1  PRU  =  64  words 
1  RB  =56  PRU' s  (3,584  words) 

35  RB 1 s  =  125,440  words 

Theoretically,  one  can  have  a  large  perm  file  saved  at  AFWL  if  it  is 
approved  by  Airman  Vickers.  To  have  a  perm  file  over  35  RB's  saved  at  AFWL 
write  to: 

Airman  Richard  Vickers 

AFWL/A0P0 

Kirtland  AFB 

New  Mexico  87117 

(505-264-7984) 

With  the  following  information: 

1.  Justification  for  the  large  file. 

2.  How  long  the  file  is  to  be  saved. 

3.  The  name  of  the  file. 


4.  Your  account  ID. 

5.  The  cycle  numbers  of  that  file  to  be  protected. 


APPENDIX  E 


VALID  PLAYERS  AND  TARGETS 

MADEM  is  a  simulation  that  interacts  with  entities  within  the  model. 
These  entities  are  in  two  catagories:  active  players  and  passive  targets. 
The  valid  players  are  the  ones  that  can  be  acted  upon  or  react.  A  passive 
target  can  only  be  acted  upon,  such  as  targets  that  can  not  defend  them¬ 
selves.  The  following  is  a  list  of  each  category  and  the  internal  code 
used  to  represent  it  in  the  model. 


Active  Players 

Name  Code 

AIR8ASE  220 

ATAF  128 

AWACS  132 

CRC  130 

HAWKBOC  150 

HAWKBTRV  170 

HERCBOC  160 

HERCBTRY  180 

PATBOC  155 

PATBTRY  175 

SOC  153 

Aircraft  Flights 

Name  Code 

BLUE  INTERCEPTORS  401-419 

RED  FIGHTERS  420-439 

RED  FIGHTER/BOMBER  440-459 

RED  BOMBERS  460-478 
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Passive  Targets 

Name  Code 
ASP  87 
BRIDGE  39 
CLVBTRY  94 
CQRPCP  95 
OEPQS  40 
OIVCP  92 
HJ  34 
LANCE  86 
PERSHING  83 
POL  84 
RESERVES  88 
SASP  210 
TAB  158 
TRAINS  89 
VIIIBTRY  90 

Special  case 

Name  Code 
SHORAD  1 
COLUMN/ROW  TOTAL  9999 
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DISTRIBUTION  LIST 


DE  PARTMENT  OF  DEFENSE 

Armed  Forces  Staff  College 

ATTN:  Reference  &  Technical  Svcs  Br 

Assistant  Secretary  of  Defense 
International  Security  Affairs 

ATTN:  European  &  NATO  Affairs 
ATTN:  Policy  Plans  &  NSC  Affairs 

Assistant  Secretary  of  Defense 
Comm,  Cind,  Cont  &  Intel  1 

ATTN:  Surveillance  &  Warning  Sys 

Assistant  to  the  Secretary  of  Defense 
Atomic  Energy 

ATTN:  Executive  Assistant 

Commander-in-Chief,  Atlantic 
ATTN:  N- 22 

Commander-in-Chief,  Pacific 
ATTN:  0-634 
ATTN:  J-54 
ATTN:  0-32 

Defense  Intelligence  Agency 

ATTN:  DI A/VPA-2 ,  Fed  Res  Div 
ATTN:  DB-6 
5  cy  ATTN:  DB-4 

Defense  Nuclear  Agency 
ATTN:  STNA 
ATTN:  NATD 
ATTN:  NATA 
4  cy  ATTN:  TITl 

Defense  Technical  Information  Center 
12  cy  ATTN:  DD 

Field  Command 
Defense  Nuclear  Agency 
ATTN:  FCPR 

Field  Command 
Defense  Nuclear  Agency 
Livermore  Branch 
ATTN:  FCPRl 

Intelligence  Center,  Pacific 
ATTN:  COMIPAC 

Interservice  Nuclear  Weapons  School 
ATTN:  TTV 

Joint  Chiefs  of  Staff 
ATTN:  0-3 

ATTN:  0-5,  Strategy  Division,  W.  McClain 
ATTN:  0-5,  Nuclear  Division 
ATTN:  J-3,  Strategic  Operations  Div 
ATTN:  SAGA/SSD 
ATTN:  SAGA/SFD 

National  Defense  University 
ATTN:  NWCLB-CR 
ATTN:  ICAF,  Tech  Lib 


DEPARTMENT  OF  DEFENSE  (Continued) 

Joint  Strat  Tgt  Planning  Staff 
ATTN:  JL 
ATTN:  JlA 
ATTN:  JP 

2  cy  ATTN:  JLTW-2 

Director 

NET  Assessment 

Office  of  the  Secretary  of  Defense 
ATTN:  Military  Assistants 

U.S.  European  Conmand 
ATTN:  J-2 
ATTN:  J-3 
ATTN:  J-LW 
ATTN:  J-5NPG 
ATTN;  J-6 
ATTN:  J-2-ITD 

U.S.  National  Military  Representative 

SHAPE 

ATTN:  U.S.  Documents  Officer 

Under  Secretary  of  Defense  for  Rsch  &  Engrg 
ATTN:  Strategic  &  Space  Sys  (OS) 
ATTN:  Tactical  Warfare  Programs 

DEPARTMENT  OF  THE  ARMY 

Deputy  Chief  of  Staff  for  Ops  &  Plans 

Department  of  the  Army 
ATTN:  DAMO-ZXA 
ATTN:  DAM0-NC 

Harry  Diamond  Laboratories 

Department  of  the  Army 
ATTN:  DELHD-N-P 

U.S.  Army  Comd  &  General  Staff  College 
ATTN:  ACQ,  Library  Div 

U.S.  Army  Concepts  Analysis  Agency 
ATTN:  CSSA-ADL 

Commander-in-Chief 

U.S.  Army  Europe  and  Seventh  Army 
ATTN:  AEAGC 
ATTN:  AEAGE 

U.S.  Army,  Nuclear  S  Chemical  Agency 
ATTN:  Library 

U.S.  Army  TRADOC  Sys  Analysis  Actvy 
ATTN:  ATAA-TAC 

U.S.  Army  War  Col  lege 
ATTN:  Library 

U.S.  Military  Academy 

Department  of  the  Army 

ATTN:  Document  Library 
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DEPARTMENT  OF  THE  NAVY 


Naval  Postgraduate  School 

ATTN:  Code  1424,  Library 

Naval  Research  Laboratory 
ATTN:  Code  1240 


Naval  Sea  Systems  Command 
ATTN:  SEA-09G53 
ATTN:  SEA-643 


Naval  Surface  Weapons  Center 
ATTN:  Code  F31 


Naval  War  Col  lege 

ATTN:  Document  Control 


Nuclear  Weapons  Tng  Group,  Pacific,  Dept  of  Navy 
ATTN:  Document  Control 


Nuclear  Weapons  Tng  Group,  Atlantic,  Dept  of  Navy 
ATTN:  Document  Control 


Office  of  Naval  Research 

ATTN:  Technical  Info  Services 


DEPARTMENT  OF  THE  AIR  FORCE 


Air  Force  Systems  Command 


ATTN: 

DL 

ATTN: 

XR 

ATTN: 

SD 

Air  Force  Weapons  Laboratory 
Air  Force  Systems  Command 
ATTN:  SUL 

Air  University  Library 
Department  of  the  Air  Force 
ATTN:  AUL-LSE 

Assistant  Chief  of  Staff 
Intel 1 igence 

Department  of  the  Air  Force 
ATTN:  INA 

Deputy  Chief  of  Staff 
Research,  Development,  &  Acq 
Department  of  the  Air  Force 
ATTN:  AFRDQI 

Foreign  Technology  Division 
Air  Force  Systems  Command 
ATTN:  CCN 
ATTN:  TQTM 
ATTN:  SDN 

Strategic  Air  Command 
Department  of  the  Air  Force 
ATTN:  NR 
ATTN:  ADWN 
ATTN:  XP 

ATTN:  NRI ,  STINFO  Library 
ATTN:  00 

U.S.  Air  Force,  Pacific 
ATTN:  XP 

Commander- in-Chief 
U.S.  Air  Forces  in  Europe 
ATTN:  USAFE/DEX 


DEPARTMENT  OF  THE  AIR  FORCE  (Continued) 

Commander-in-Chief 
U.S.  Air  Forces  in  Europe 
ATTN:  USAFE/DOT 

Commander-in-Chief 
U.S.  Ait  Force  in  Europe 
ATTN:  USAFE/1NA 

Commander-in-Chief 
U.S.  Air  Forces  in  Europe 
ATTN:  USAFE/INT 

Commander-in-Chief 
U.S.  Air  Forces  in  Europe 
ATTN:  USAFE/XPX 

USAF  Tactical  Fighter  Weapons  Center 
ATTN:  Cotrmander 

DEPARTMENT  OF  ENERGY 

Department  of  Energy 
Albuquerque  Operations  Office 
ATTN:  CTID 

OTHER  GOVERNMENT  AGENCY 

Central  Intelligence  Agency 
ATTN:  OSWR/NED 

DEPARTMENT  OF  ENERGY  CONTRACTORS 

Lawrence  Livermore  National  Lab 

ATTN:  Tech  Info  Dept,  Library 

Los  Alamos  National  Lab 
ATTN :  MS  364 
ATTN:  M/S634,  T.  Dowler 

DEPARTMENT  OF  DEFENSE  CONTRACTORS 

Advanced  International  Studies  Institute 
ATTN:  M.  Harvey 

Aerospace  Corp 

ATTN:  Library 

BDM  Corp 

ATTN:  J.  Braddock 
4  cy  ATTN:  M.  Filteau 
4  cy  ATTN:  T.  Hawkins 
4  cy  ATTN:  L.  Elfes 
4  cy  ATTN:  B.  Macaleer 
4  cy  ATTN:  J.  Phi  11 ips 

JAYCOR 

ATTN:  R.  Sullivan 

Kaman  Sciences  Corp 

ATTN:  F.  Shelton 

Kaman  Sciences  Corp 
ATTN:  E.  Daugs 

Kaman  Tempo 

ATTN:  DAS  I AC 

Pacific-Sierra  Research  Corp 
ATTN:  G.  Lang 
ATTN:  H.  Brode 
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DEPARTMENT  OF  DEFENSE  CONTRACTORS  (Continued) 

Pacif ic-Sierra  Research  Corp 
ATTN:  D.  Gormley 

R  &  D  Associates 

ATTN:  R.  Port 
ATTN:  P.  Haas 
2  cy  ATTN:  Document  Control 
2  cy  ATTN:  S.  Borjon 

R  &  D  Associates 

ATTN:  J.  Thompson 

Science  Appl ications,  Inc 

ATTN:  Document  Control 
ATTN:  J.  Warner 
ATTN:  M.  Drake 

Science  Applications,  Inc 
ATTN:  W.  Layson 
ATTN:  Document  Control 


DEPARTMENT  OF  DEFENSE  CONT RACTORS  (Continued) 

Science  Applications,  Inc 
ATTN:  D.  Kaul 
ATTN:  L.  Goure 

System  Planning  Corp 

ATTN:  J.  Douglas 

Tetra  Tech,  Inc 

ATTN:  F.  Bothwell 

TRW  Defense  &  Space  Sys  Group 
ATTN:  N.  Lipner 

TRW  Defense  &  Space  Sys  Group 
ATTN  P.  Dai 
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